Сложные системы не прощают мутных историй
Пятнадцать лет я формулирую рабочие истории — сначала нащупывая метод сам, потом обучая ему коллег и специалистов из разных компаний. Категории рабочей истории — Носитель, Ситуация, Действие, Объекты, Цель, Форма реализации, Интерфейсная структура — появились не сразу: это результат многолетнего разбора того, что идёт не так, когда команда работает с требованиями. Готовые категории в шаблоне — уже большая часть работы: с ними уже не перепутать цель с деталью реализации.
Но даже с шаблоном в руках хорошую историю по нему пишут единицы. Разница между теми, кто просто заполняет поля, и теми, кто пишет сильные истории, — в умении увидеть, где цель действия ещё не отделилась от красиво сформулированной детали реализации, и понимании когда именно допустимо остановиться, если ситуация описана уже достаточно точно.
Ремесло сплетения историй заметно в любой роли, где вообще имеют дело с инженерией требований.
⚫️ В продукте — историю закрывают, когда пройден технический критерий приёмки, а проверка, что при этом достигнута цель действия, часто вообще не происходит.
⚫️ В дизайне интерфейса — макет не выдерживает первый же нетиповой сценарий, потому что нарисован раньше, чем стало понятно, с чем в действительности работает использующий его человек.
⚫️ В сборе требований — хотелка заказчика превращается в задачу для разработки без ответов на вопросы «зачем делать вообще» и «зачем именно так».
⚫️ В командной работе — аналитик, дизайнер и разработчик обсуждают «одну» историю на разных диалектах, и смысл теряется на стыке.
⚫️ В цифровых сервисах для госсектора и НКО — услугу чаще проектируют от формы и регламента, а вопрос, зачем человек вообще сюда пришёл, звучит в последнюю очередь, если звучит вообще; тогда и вскрывается, что часть процедуры не нужна вовсе, и она мешает потребителю.
⚫️ При планировании релизов — истории группируют в этапы по техническому удобству, что легче задеплоить вместе, и потому случаются релизы, где вся функциональность вроде бы готова, но без соседнего куска бесполезна потребителю.
Когда рабочая история наконец сплетена и чиста от форм реализации, решения по ней находятся в разы быстрее, получаются разнообразнее и интереснее. Их легко варьировать, потому что ничего в формулировке уже не тянет мысль в сторону одного конкретного варианта: инструмента, экрана, кнопки. Вместо слепого перебора вариантов в проектировании появляется управляемость: понятно, в какую сторону двигаться и почему.
На курсе по Карте реализации историй я учу этому ремеслу — технике сплетения истории, шаг за шагом, поверх шаблона из семи категорий.
17 августа стартует новый поток. Присоединяйтесь, чтобы освоить действенную технику проектирования от инженеров, работающих со сложными системами
Программа и запись
Пятнадцать лет я формулирую рабочие истории — сначала нащупывая метод сам, потом обучая ему коллег и специалистов из разных компаний. Категории рабочей истории — Носитель, Ситуация, Действие, Объекты, Цель, Форма реализации, Интерфейсная структура — появились не сразу: это результат многолетнего разбора того, что идёт не так, когда команда работает с требованиями. Готовые категории в шаблоне — уже большая часть работы: с ними уже не перепутать цель с деталью реализации.
Но даже с шаблоном в руках хорошую историю по нему пишут единицы. Разница между теми, кто просто заполняет поля, и теми, кто пишет сильные истории, — в умении увидеть, где цель действия ещё не отделилась от красиво сформулированной детали реализации, и понимании когда именно допустимо остановиться, если ситуация описана уже достаточно точно.
Это умение приходит только через практику: черновик истории многократно переписывается, лишнее счищается, ёмкие формулировки стягиваются к самой сути.
Ремесло сплетения историй заметно в любой роли, где вообще имеют дело с инженерией требований.
⚫️ В продукте — историю закрывают, когда пройден технический критерий приёмки, а проверка, что при этом достигнута цель действия, часто вообще не происходит.
⚫️ В дизайне интерфейса — макет не выдерживает первый же нетиповой сценарий, потому что нарисован раньше, чем стало понятно, с чем в действительности работает использующий его человек.
⚫️ В сборе требований — хотелка заказчика превращается в задачу для разработки без ответов на вопросы «зачем делать вообще» и «зачем именно так».
⚫️ В командной работе — аналитик, дизайнер и разработчик обсуждают «одну» историю на разных диалектах, и смысл теряется на стыке.
⚫️ В цифровых сервисах для госсектора и НКО — услугу чаще проектируют от формы и регламента, а вопрос, зачем человек вообще сюда пришёл, звучит в последнюю очередь, если звучит вообще; тогда и вскрывается, что часть процедуры не нужна вовсе, и она мешает потребителю.
⚫️ При планировании релизов — истории группируют в этапы по техническому удобству, что легче задеплоить вместе, и потому случаются релизы, где вся функциональность вроде бы готова, но без соседнего куска бесполезна потребителю.
Когда рабочая история наконец сплетена и чиста от форм реализации, решения по ней находятся в разы быстрее, получаются разнообразнее и интереснее. Их легко варьировать, потому что ничего в формулировке уже не тянет мысль в сторону одного конкретного варианта: инструмента, экрана, кнопки. Вместо слепого перебора вариантов в проектировании появляется управляемость: понятно, в какую сторону двигаться и почему.
На курсе по Карте реализации историй я учу этому ремеслу — технике сплетения истории, шаг за шагом, поверх шаблона из семи категорий.
17 августа стартует новый поток. Присоединяйтесь, чтобы освоить действенную технику проектирования от инженеров, работающих со сложными системами
Программа и запись