Comments 6
Коммуникация, безусловно, важна, в процессе ведения проекта, но описанный здесь вариант реализации - MVP(быстро и недорого) + доработки(качественно), используется в индустрии настолько давно, что уже считается чуть ли не стандартом.
Каким образом, увеличение количества коммуникаций позволит данному паттерну лучше вписываться в треугольник ограничений?
Кмк, когда надо пилить быстро, созвоны не добавляют ценность, а отбирают время у команды
MVP + допилить - да, стандарт. А я считаю, что это только один из трех вариантов. Когда приходит 10 задач, а ресурсов есть на 5 (а так часто бывает и в проектных офисах и во внутреннем ИТ), просто запилить MVP по всем можно и не успеть - все равно ресурсов то только на 5.
вот тут и начинается игра "кто умрет" и поиск ресурсов. Выстрелить может любой, по опыту.
Что до коммуникаций - все просто. Заказчик считает, что MVP - это одно, команда считает - другое. РП надо поговорить и с теми, и с теми (о да, заказчиков бывает много и у каждого свое представление о счастье). С разрабов желательно получить несколько вариантов, чтобы была переговорная вилка для заказчика. Далее идем по заказчикам, получаем замечания, затем к команде, к линейному (сроки, приоритеты), затем к заказчику...
Я готов ответственно сказать на личном опыте и опыте моих менеджеров: если РП сокращает коммуникации, отделываясь формальным общением, это приводит к недоверию на проекте между всеми сторонами (заказчик-РП-команда). Это может быть некритично, если проект разовый, РП сделал в срок и все ок. Это может быть критично, если это не просто РП, но он отвечает за развитие продукта заказчика.
Когда я был молодым разрабом, навалили мне 5 менеджеров супер важных задач. И каждый требовал, чтоб я решил его задачу через 2 недели. Когда я сказал, что это просто физически не возможно и что они не правильно оценивают объем каждой задачи, мне было сказано, что я просто не знаком с Тайм Менеджментом и они меня научат. Мне было поручено расписать этапы разработки по каждой из этих 5-ти задач. На это было потрачено пару дней. Получилось, что мне потребуется на их решение 6 месяцев. Что сделали менеджеры? Они стерли сроки из моего списка и отдали на оценку другим разрабам (я об этом не знал). Что они получили? Вдвое большие оценки!
Сейчас, как мне кажется, единственный правильный вариант, после всех оценок, это выставление приоритетов каждой задаче. Причем, выставлять их должны не разрабы, а бизнес-заказчики. Пусть бизнес решает, что нужно в первую очередь. По опыту, скажу, что до решения низкоприоритетных задач, часто даже дело не доходит. Оно становится не нужным, ошибочным, не актуальным.
Да, очень хорошо вас понимаю. У вас отличный пример, когда менеджер идет полностью на поводу у клиента, подставляя команду под нереальные сроки.
А, впрочем, может и нет: у вас же просто спросили оценку, обоснование, а после - просто еще раз уточнили, осознали и приняли :)
Я еще напишу про "чайка-менеджеров" поподробнее, это большая тема. И о том, что можно сделать чтобы защитить команду. И про то, что менеджер, в моем понимании, должен быть помощником команде и прикрывать ее от безумия бизнеса (безумие условно, но разработчику лучше не знать, что там заказчик рвет и мечет. Менеджер для этого есть, а инженер должен тихонько сидеть и пилить согласно плана и своей оценке).
Как делать ваши проекты Быстро, Качественно и Недорого?