Комментарии 10
Если дал оценку под дедлайн проекта и не успел – значит надо поработать ночью (да, за ошибку в оценке есть ответственность).
Как итог в следующий раз сроки будут завышены. Запомните разработчик ни при каких обстоятельствах не должен работать вечером, в выходные или ночью. Исключение только если сам захотел и то не более одного выходного в месяц.
Ну и норм, если их согласовали. Бизнес любит предсказуемость.
А ничего страшного нет, если человек дал неправильную оценку, понес ответственность и в следующий раз оценку увеличивает. Я всегда говорю про баланс, он и тут нужен: оценка не должна быть слишком оптимистичной, оценка должна быть при этом не сильно завышенной (сильно завышенные - очень видны и их легко увидеть нормальному РП).
Адзизес (это такой гуру бизнес управления) говорил, что любой менеджер - это вообще любой человек, давший срок по своей работе. Далее он управляет всеми стандартными потоками (объем, риски, коммуникации), только в миниатюре, в одной своей задаче.
Умение предвидеть проблемы, умение их решать очень отличает джуна от мидла, а мидла от синьора.
Странный РП, который позволяет бизнесу напрямую ходить к разработчику. Гнать таких надо, чтобы сберечь команду.
Я больше скажу. Бывает, что это даже не РП, а CIO компании , который не против такой прямоу коммуникации, потому что "мы за бизнес, любое пожелание бизнеса нам важно". За последний год две такие компании наблюдал. И оба CIO зашивались от кучи текучки, бизнес был недоволен, разработчики выгорали. И ничего не менялось. Хаос и бардак.
выстроил все коммуникации по объему, срокам и оценкам через себя (я просто разрешил лиду вообще не отвечать на эти вопросы и говорить «поговорите с Петром, это к нему»).
Я тоже всегда считал, что исполнители должны быть ограждены от излишнего общения с заказчиком, оно допустимо только при острой необходимости и если разработчик сам готов к этому. Иначе это превращается в бесконечный поток задач или уточнений, особенно если заказчик инициативный. Но это же противоречит современному эджайл-подходу "в Agile команда разработчиков постоянно общается с заказчиком", как вы примиряете два подхода - сейчас же тех кто "не работает по эджайлу" предают анафеме?
хороший вопрос. сходу ответ в том, что agile явно не относится к системной интеграции, потому что там есть контракт и заказчику плевать на то, как вы работаете: соберите требования нормально и сдайте :)
но ведь я видел много внутренних команд, которых бизнес задолбал, весь Agile превратился в дырявое ведро, где 70% задач внеплановые (реально). Где там дырка в подходе надо отдельно подумать. Напишу еще :)
Я-то как раз отлично представляю, что такое дать возможность заказчику, особенно внутреннему, общаться с исполнителями - они начинают их грузить - нет, не работой, ни в коем случае, а маленькими доработочками, вопросиками и исправленьицами - только бесконечными, как вы написали процентов на 70.
Может тогда ещё напишете пару слов про то, что откуда берётся уверенность, что вообще самому заказчику нужно "общение с командой проекта" (это перекликается с вашей недавней статьёй про руководителей и вопросы от подчинённых). У него дел и так по горло, он платит деньги проектной команде чтобы они решали его проблемы, а не добавляли головной боли. Всегда есть выбор - набрать разрабов и руководить самому или использовать стороннюю команду. И если трудозатраты на взаимодействие с "командой" сопоставимы с руководством собственной, то проект можно реализовать кратно дешевле и со всеми своими хотелками.
Руководитель ИТ проектов и его команда: как выстраивать отношения правильно?