Pull to refresh

Comments 13

Что, одним письмом и процессы у подрядчика и качество продукта подтянул? Мощь…
UFO landed and left these words here
А мне письмо понравилось тем, что нет угроз, менеджер явно заинтересован в цели и мотивирует подрядчика. Сама же идея описывается в ряде книг, «Как пасти котов» и в руководствах по итерационным методикам разработки.
Детский сад какой-то. Такое ощущение, что писал человек без опыта работы (отправил магическое письмо и всё сразу разрулилось у него), который начитался литературы по теме и решил собрать воедино core-пункты. Да, да, все правила кровью написаны, мудрость поколений ПМ…
Встать на сторону заказчика.

Бред примерно того-же уровня, что и "посмотреть на продукт глазами пользователя". Нет никакого универсального сферического в вакууме "пользователя" или "заказчика". Приоритеты всегда видны только в области компетенций, а процессы оцениваются только в рамках собственного субъективного опыта. Все остальное — иллюзии, которые ни к чему хорошему никогда не приведут. Никто не сможет "залезть" в голову заказчику, не умеющему четко формулировать свои мысли.


Честность, уважение и сдержанность.

Не хватает слова "взаимная". Все имеют равные права на "тараканов в голове", как и право слать куда подальше мудаков, с которыми работать не комфортно. У хороших специалистов всегда есть выбор, проектные менеджеры должны четко это осознавать. Разработчик — не ваш личный психолог, и его работа вовсе не заключается в том, чтобы успокаивать заказчика. Это я к тому, что разработчики часто сталкиваются со сложными техническими ситуациями, которые могут давать довольно высокую психологическую нагрузку. Иногда люди, в такой ситуации, срываются, и совершенно не беспочвенно, стоит быть внимательными друг к другу обоюдно.


Коммуникация! Коммуникация! Коммуникация!

Бред. Перегибы с коммуникацией часто сильно вредят процессу. Хотя бы на том уровне, где для решения задач требуется высокий уровень сосредоточенности, и все внешние раздражители и переключения фокуса — очень нежелательны. В команде обязательно должен быть человек, ответственный за процесс, который может оградить исполнителей от лишнего формализма и излишних коммуникаций, способный самостоятельно предоставить заказчику необходимую актуальную информацию.


Вы, наверное, могли подумать, что все вышеизложенное — мнение вредного и несговорчивого разработчика? Но нет, я все это пишу именно с позиции менеджера, но имеющего технический бэкграунд.

Никто не сможет "залезть" в голову заказчику, не умеющему четко формулировать свои мысли.

Перегибы с коммуникацией часто сильно вредят процессу.

Вашими бы устами, да мёд пить.

А в чем проблема? Вы нашли какое-то противоречие в этих цитатах? Поделитесь какое именно?

Нет-нет, это не сарказм, я имел в виду, если бы все эти очевидные вещи понимали, жить было бы намного лучше.

Сами же вначале сказали:
> А потом с подрядчиками что-то случилось. Толи они поменяли менеджера, толи разработчиков перекинули на другой проект и оставили ему джунов, толи еще что-то.
Так что, это "что-то" куда-то делось после письма? Если нет, то с чего бы "дела пошли хорошо"?
> Без четких правил и дисциплины любой процесс взаимодействия разваливается
Так каким же образом заказчик навязывает эти правила и следит их выполнением в данном случае? Одним этим письмом? А если домысливать, то получается это статья типа "Как нарисовать сову", т.е. ни о чём.

«Заказчик может говорить одно, подразумевать другое, а ожидать третье.» — это лучше выяснять на старте и по возможности с такими товарищами не работать. Если у заказчика нет понимания, что собой представляет ЕГО продукт (подчеркну, не технических особенностей, а просто «что он должен делать»), то тут ничем не поможешь.

«Но раз уж он работает с вами, это что-то значит.» — значит только то, что компании в этот момент времени подвернулся этот заказ и он почему-то был признан выгодным. Поменьше «небожительства», пожалуйста.
сдержанность: старайтесь сдерживать свои эмоции в общении и в переписке.

Коммуникация! Коммуникация! Коммуникация!
Что-то попахивает микроменеджментом чужой команды. Видеть комментарии разработчика по таскам в трекере, да еще и не меньше двух, это вот оно самое «дайте поуправлять вашей командой, раз ваш менеджер не справляется». Стэнд-апы каждый день со ВСЕЙ командой — оттуда же. РМ (Project Manager) заказчика должен работать с РМ исполнителя, а не с разработчиками исполнителя.
Судя по всему, у исполнителя как раз и ушел РМ, и заказчик взял на себя эту функцию. Вам повезло, что команда не была занята на другой задаче, иначе аутстаффинг бы провалился. Иначе говоря, это не ваша заслуга, а просто везение.
Sign up to leave a comment.

Articles