Мы не можем это релизить в срок, тут архитектура неидеальна
Обычно перфекционисты - это очень ценные люди. Они приносят много разных идей - как улучшить процесс, автоматизировать рутину, оптимизировать сбор данных. И важно эту ценность сохранить и бережно направлять их. Но есть одно но.. Можно бесконечно смотреть на три вещи. И одна из них - как человек пытается выполнить задачу идеально, несмотря ни на что, в том числе на дедлайны. И вроде ж хорошо, человек старается на благо репутации, прогресса и человечества в целом. Но вот вопрос: а что такое это «идеально» и стоит ли оно тех трудозатрат? Усложняется задачка, когда человеку повесили лычки самого крутого спеца в своей области. Ничем ему не докажешь, что стоит остановиться. Например, автоматизация получения тестовых данных невероятно полезна, но данные уже есть, и можно уже отдать результат. Но ему хочется сделать универсальнее, потому что выгружать данные руками это не тру. Я выработала следующий подход, сместить фокус с "идеальности" на "какие задачи мы решаем данными улучшениями": 1️⃣ Считаем ROI (окупаемость). Обсуждаем с человеком оценку улучшений и запрашиваем реальный эффект. Если мы сэкономим на текущем тестировании больше времени, чем потратим на улучшение прямо сейчас — почему бы и нет? 2️⃣ Откладываем в бэклог (Техдолг). Если ценность есть, но она в далекой перспективе, то запланировать улучшение и положить в беклог. (например, получение новых тестовых данных потребуется только при следующей итерации тестирования). Фиксируем задачу, чтобы спокойно доработать фичу в технический долг, а не заниматься ей прямо сейчас. 3️⃣ Идем к стейкхолдерам. Если эффект есть, но он для клиента. Оформляем как идею/фичу. Либо продлеваем сроки, либо планируем в следующий релиз. 4️⃣ Опираемся на DoD. Если глобального эффекта нет, или он незначительный, останавливаем доработки и фиксируем результат по критериям Definition of Done. 5️⃣ Подсвечиваем ценность предложений для человека. Очень важно, чтобы у спеца не сложилось впечатление, что его «задавили дедлайнами» и строгим менеджером. Хвалим за крутые предложения, объясняем, что мы их не выбрасываем, а просто приоритезируем. Этот подход не раз оправдывал себя и позволял работать вдолгую с хорошими людьми, которые болеют за результат. А как вы договариваетесь с командой, когда хочется «еще чуть-чуть улучшить» в ущерб дедлайну? #ProjectManagement#ITLeadership #Agile #УправлениеКомандой#ProjectManager #SoftSkills #Delivery
· 28.07
Перфекционисты должны работать на начальном этапе, дальше лучше их к проекту не подпускать - они не остановятся и сорвут все дедлайны. У них природа такая: они же терпеть не могут, если что-то не так стоит или лежит. То же самое и с проектами. Нет ничего идеального, а код проекта можно улучшать до бесконечности. У нас же дедлайн, и нужно сосредоточиться на исправлении багов, а не на вылизывании архитектуры.
Вот тут-то и на сцену выходят прагматики. Прагматик не заметит некоторые мелкие несовершенства архитектуры, ибо ему важно успеть в срок и сосредоточиться на багах.
А перфекционист скажет: «Вот тут надо сделать абстракцию, вдруг мы будем расширять классы в будущем», «А вот здесь нужен рефакторинг», «О, гляди, тут малость грязный код, его исправить нужно». И тут его стремление к красоте играет с ним злую шутку - падением производительности в два раза.
Почему? Да все потому, что код, который был неказист на вид, был гораздо быстрее. С этим кодом была проведена оптимизация производительности, а этот чудик полез и все испортил в угоду красоте.
Вот и получается: красота - красотой, а шевеления никакого. А у нас скоро дедлайн! И пока перфекционист возился с архитектурой, он начисто забыл о багах, которые нужно было исправить перед релизом. Ибо ему была важнее чистота кода и архитектура, а баги - потом.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 28.07
да, важно найти баланс между дедлайнами и красотой
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён