Раньше я с ноги врубался в задачу и пилил до победного. Сквозь боль, слёзы, баги и сорванные сроки. Всё изменилось, когда я начал лидить команду и больно ударился о недостаточно проработанные задачи. Предварительно оценённый эпик мог вырасти примерно на 30%.
Мы стали уделять больше времени грумингу фич. Команда отметила два изменения:
- Стало понятно, как фича работает с точки зрения бизнеса, как встраивается в процессы и какие краевые случаи нужно учесть.
- Ещё до первой строки кода стало примерно понятно, как решение будет выглядеть в системе.
Меня зацепило это «примерно». Поэтому мы добавили техническую проработку и ревью решения до написания кода. Мы фактически отделили думанье от деланья. По хорошо проработанной спеке программировать оказалось намного проще.
Со стороны процесс казался бюрократичным: много грумингов, много «бумажек». На деле эти затраты перенесли часть сложности туда, где ошибку ещё дёшево исправить.
Но идеальной спеки всё равно не будет. Забудут специфичный сценарий, не опишут API или не продумают часть функционала. Здесь от senior-инженера я жду не возмущения по поводу неидеального мира, а поиска ответа и движения задачи вперёд.
Граница здесь важна. Инженер не должен молча принимать на себя чужую работу или угадывать критические требования. Если пробел мешает принять безопасное решение, нужно остановиться и вернуть вопрос владельцу требований.
Мой рабочий компромисс такой:
- До разработки письменно проработать бизнес-сценарии и техническое решение.
- Не пытаться сразу написать идеально. Сначала выгрузить структуру и мысли, затем довести их до целого.
- Считать спеку инструментом снижения известной неопределённости, а не гарантией, что неожиданностей не будет.