🧱 Я обожаю Lego!
Да я бородатый дядька чуть за 30 и я люблю собирать Лего и что вы мне сделаете? 😁
Оно меня успокаивает, это моя некая форма медитации (прости Господи)
На днях как-то собирал Lego и поймал себя на неприятной мысли: иногда инструкция понятнее, чем ТЗ в реальном проекте.
В инструкции Lego тебе не говорят:
«Собери нормальную машину. Чтобы красиво, удобно и желательно к пятнице».
А теперь посмотрим на типичное требование в проекте:
«Пользователь должен иметь возможность отменить заказ».
Формально всё ясно. По сути — вообще ничего.
Кто именно может его отменить? В каком статусе это ещё возможно? Что произойдёт с оплатой? Что делать, если курьер уже выехал? Какая система узнает об отмене первой?
Вот тут и начинается работа системного аналитика.
Не написать побольше текста. А договориться с командой, какие состояния есть у системы, что меняется на каждом шаге и какой результат мы считаем правильным.
Плохое ТЗ похоже на фразу:
«Соберите вот такую штуку, а детали по ходу разберём».
Хорошее ТЗ не убирает все вопросы. Оно помогает задавать правильные вопросы до того, как команда потратила время и собрала не ту конструкцию.
И вот за это я люблю хорошие инструкции Lego.
Они не делают задачу примитивной. Они делают её выполнимой.
В проектах, правда, иногда обнаруживаются детали, которых вообще не было в коробке, но это нюансы 😁
Делитесь, а у вас какие есть хобби увлечения? У кого тоже как у меня "детские"? 👇🏻
@life_in_analytics
Да я бородатый дядька чуть за 30 и я люблю собирать Лего и что вы мне сделаете? 😁
Оно меня успокаивает, это моя некая форма медитации (прости Господи)
На днях как-то собирал Lego и поймал себя на неприятной мысли: иногда инструкция понятнее, чем ТЗ в реальном проекте.
В инструкции Lego тебе не говорят:
«Собери нормальную машину. Чтобы красиво, удобно и желательно к пятнице».
Там всё немного честнее.
Вот детали, которые нужны сейчас. Вот порядок действий. Вот как выглядит результат этого шага. Вот что добавляем дальше. Ты можешь ошибиться, конечно. Повернуть деталь не той стороной, взять не тот элемент, пропустить страницу.
Но хотя бы понятно, что именно ты сейчас собираешь и как проверить, что собрал правильно.
А теперь посмотрим на типичное требование в проекте:
«Пользователь должен иметь возможность отменить заказ».
Формально всё ясно. По сути — вообще ничего.
Кто именно может его отменить? В каком статусе это ещё возможно? Что произойдёт с оплатой? Что делать, если курьер уже выехал? Какая система узнает об отмене первой?
Вот тут и начинается работа системного аналитика.
Не написать побольше текста. А договориться с командой, какие состояния есть у системы, что меняется на каждом шаге и какой результат мы считаем правильным.
Плохое ТЗ похоже на фразу:
«Соберите вот такую штуку, а детали по ходу разберём».
Хорошее ТЗ не убирает все вопросы. Оно помогает задавать правильные вопросы до того, как команда потратила время и собрала не ту конструкцию.
И вот за это я люблю хорошие инструкции Lego.
Они не делают задачу примитивной. Они делают её выполнимой.
В проектах, правда, иногда обнаруживаются детали, которых вообще не было в коробке, но это нюансы 😁
Делитесь, а у вас какие есть хобби увлечения? У кого тоже как у меня "детские"? 👇🏻
@life_in_analytics