Знаете эту ситуацию: приходит задача от продукта, а там буквально три строчки. Ни зачем это надо, ни как должно работать, ни по каким критериям поймём, что всё получилось.
И тут начинается магия додумывания. Каждый разработчик берёт эти три строчки и докручивает в голове свою версию. Кто-то решит, что надо сделать максимально надёжно и накидает кучу проверок. Кто-то сделает попроще, потому что «и так сойдёт». А в итоге получается… ну, не то. И потом все дружно исправляют: ночами, в спешке, когда сроки уже горят.
Любая неточность бьёт не только по нашей работе, но и по людям, которые пользуются сервисом. Хочется ведь делать хорошо и с первого раза.
Что помогает мне как тимлиду не попадать в эту ловушку:
Проговаривать с командой простое правило: если в задаче непонятно «зачем» и «как узнаем, что хорошо», мы её не берём. Лучше пять минут потратить на уточнение, чем пять часов на переделку.Договариваться с продуктом: цель, ограничения, пример ожидаемого результата. Даже если это черновик — уже спасает от разночтений.Если чего-то не знаем — честно говорим: «Пока данных нет, решение будет позже. Работаем по старому плану». Это снимает тревогу и убирает почву для слухов.Все изменения кидаем в одно место и помечаем: «обновили требования». Чтобы никто не думал, что «всё осталось как было».Иногда самое ценное, что тимлид может дать команде, — это не новую фичу и не крутой инструмент, а просто понятный контекст.
А у вас бывало: сделали по задаче, а потом оказалось, что все думали про разное?
