ПМы-альтруисты, сосиски и тот свет.
если Вы хотите узнать, что связывает эти понятия, прошу:
ПМ-альтруист
Настоящий менеджер должен быть самоотверженным. Неэгоистичным. Он должен понимать, чем живет его команда, что нравится людям, с которыми он работает. После «бурной ночи» релиза для него должно быть важнее то, что пострадали разработчики. Кроме того, он должен понимать, что ответственность за ночные посиделки, кроме всяких там злых боссов и начальников, несет именно он, т.к. он представляет интересы разработчиков в «высших кругах».
Разработчики, зачастую, готовы помочь и пойти навстречу. Особенно если речь идёт об их собственных ошибках и погрешностях. Если я озвучил определенные сроки, и не могу в них уложиться, я согласен буду задержаться на работе, либо прийти пораньше, но слово сдержать постараюсь. Другой вопрос — когда я озвучил срок, его урезали вдвое, и пинают за то, что я в него не смог уложиться. Но уложиться в него я заведомо не мог, поскольку мне нужно вдвое больше времени. Здесь, именно здесь, на этапе планирования, ПМ должен впервые вступиться за своего программиста, и отстоять сроки, данные им. но также он должен и проконтролировать выполнения задания в срок. Если нужно — напомнить, что завтра — сдача. Возможно — просмотреть промежуточные результаты работы. Это поможет понять, на каком ты свете.
Ну вот, ПМ отстоял время, которое озвучил программист, доказал, что он объективен, объяснил, что лучше на спичках и соли не экономить, поскольку каши без них не сварить, и всё такое. Но вот приходит следующий день. Новое задание. Горящее, так сказать. Так вот. На этом этапе — очень важно не забыть, что сроки, данные на выполнения текущего задания — раздвигаются. И время на его выполнения будет в любом случае больше, поскольку человеку требуется некоторое время на переключение между задачами. Если планы не сдвигать, то мы либо сорвем сроки, либо заставим разработчика тратить своё личное время. И то и другое — демотивирует, что, в свою очередь, замедляет разработку.
Справились. Сделали все горящие задачи, все текущие, все бессонные ночи позади. Здесь важно вспомнить о том, что проект сделал не ПМ, а вся команда. Подвести итоги. Сказать, что было хорошо, а что — нужно исправить. И побольше объективности. Если заставил человека работать сверхурочно — изволь отметить это, и предложить варианты исключить подобные случаи в будущем, или, хотя бы, минимизировать подобные риски.
Сосиски
Сосиски — заведомо ложная мотивация. «Сдадим проект, тогда...», «Разработаем этот кусок, тогда...», ну и все подобные высказывания. Рано или поздно мы все понимаем, что сосиска, за которой мы гонимся, просто летит перед нами, и догнать её мы не сможем, поскольку палка, на которой она висит, привязана к нашей спине. Будьте реалистами. Скажите честно: «ребят, мы по уши в повидле», «нам придётся туго». Думаете, что все разбегутся? Сомневаюсь. Может, трудности, и не сближают людей, но, по крайней мере, мы понимаем, на каком мы свете, что очень важно.
Чтобы проблему решить, нужно её локализовать и озвучить. иначе она так и будет витать в воздухе. все будут чувствовать, что что-то их смущает, но, помятуя о «сосисках», озвучить её так и не решатся. озвучишь — лишишься сосиски. вот и бегай за ней. Кроме того, если вы сами не верите, что сосиска упадёт вам в рот, люди, окружающие вас, смогут себя ей только тешить. Но мотивации от этого не прибавится.
В погоне за сосисками вам помогут простые инструменты, такие как планирование, код-ревью и рефакторинг. Спланировав всё тщательно, вы будете иметь представления о дате соприкосновения с сосиской. Код-ревью подскажет, не убежала ли сосиска из-под вашего носа, а рефакторинг поможет вернуть сбежавшую сосиску.
Пришел запрос на новую функциональность. Мы его спланировали. Реализовали. Сидим, ждем сосиску. Из-за отсутствия код-ревью мы узнаем о том, что всё, над чем мы трудились многие дни, работает, как минимум, некорректно и не оптимально. А за отсутствия рефакторинга мы будем осуждены на вечные скитания по баг-трекинговой системе и коду в поисках того самого, последнего бага, за которым покоится сосиска. Но, как нам всем уже известно, он всегда будет предпоследним.
Тот свет
Проверяйте свои vital signs ежедневно. Купите себе тонометры, тахометры, пульсометры, осциллографы, и всё что может помочь в этом, и используйте по назначению. При отсутствии признаков жизни с вашей стороны, сосиска достанется другому. Ваш проект должен хотя бы шевелиться, чтобы вы смогли его закончить. Если же пациент больше мертв, нежели жив (как у Филиппа Дика), то вам поможет только Убик. Либо хиромантия. Либо спиритизм. Всё, что может помочь общаться с теми, кого с нами уже нет. лучше предупредить, чем разбираться с последствиями.
И пусть ваш проект живет долго. Но не слишком долго живет в разработке.
При написании сего поста ни одного менеджера не пострадало. Слова «должен», «обязан» относятся к эвфемическим категориям, и реальны исключительно в моей «параллельной реальности».
и, да… забудьте обо всем, что я написал, если ваши программисты пишут идеальный код.
если Вы хотите узнать, что связывает эти понятия, прошу:
ПМ-альтруист
Настоящий менеджер должен быть самоотверженным. Неэгоистичным. Он должен понимать, чем живет его команда, что нравится людям, с которыми он работает. После «бурной ночи» релиза для него должно быть важнее то, что пострадали разработчики. Кроме того, он должен понимать, что ответственность за ночные посиделки, кроме всяких там злых боссов и начальников, несет именно он, т.к. он представляет интересы разработчиков в «высших кругах».
Разработчики, зачастую, готовы помочь и пойти навстречу. Особенно если речь идёт об их собственных ошибках и погрешностях. Если я озвучил определенные сроки, и не могу в них уложиться, я согласен буду задержаться на работе, либо прийти пораньше, но слово сдержать постараюсь. Другой вопрос — когда я озвучил срок, его урезали вдвое, и пинают за то, что я в него не смог уложиться. Но уложиться в него я заведомо не мог, поскольку мне нужно вдвое больше времени. Здесь, именно здесь, на этапе планирования, ПМ должен впервые вступиться за своего программиста, и отстоять сроки, данные им. но также он должен и проконтролировать выполнения задания в срок. Если нужно — напомнить, что завтра — сдача. Возможно — просмотреть промежуточные результаты работы. Это поможет понять, на каком ты свете.
Ну вот, ПМ отстоял время, которое озвучил программист, доказал, что он объективен, объяснил, что лучше на спичках и соли не экономить, поскольку каши без них не сварить, и всё такое. Но вот приходит следующий день. Новое задание. Горящее, так сказать. Так вот. На этом этапе — очень важно не забыть, что сроки, данные на выполнения текущего задания — раздвигаются. И время на его выполнения будет в любом случае больше, поскольку человеку требуется некоторое время на переключение между задачами. Если планы не сдвигать, то мы либо сорвем сроки, либо заставим разработчика тратить своё личное время. И то и другое — демотивирует, что, в свою очередь, замедляет разработку.
Справились. Сделали все горящие задачи, все текущие, все бессонные ночи позади. Здесь важно вспомнить о том, что проект сделал не ПМ, а вся команда. Подвести итоги. Сказать, что было хорошо, а что — нужно исправить. И побольше объективности. Если заставил человека работать сверхурочно — изволь отметить это, и предложить варианты исключить подобные случаи в будущем, или, хотя бы, минимизировать подобные риски.
Сосиски
Сосиски — заведомо ложная мотивация. «Сдадим проект, тогда...», «Разработаем этот кусок, тогда...», ну и все подобные высказывания. Рано или поздно мы все понимаем, что сосиска, за которой мы гонимся, просто летит перед нами, и догнать её мы не сможем, поскольку палка, на которой она висит, привязана к нашей спине. Будьте реалистами. Скажите честно: «ребят, мы по уши в повидле», «нам придётся туго». Думаете, что все разбегутся? Сомневаюсь. Может, трудности, и не сближают людей, но, по крайней мере, мы понимаем, на каком мы свете, что очень важно.
Чтобы проблему решить, нужно её локализовать и озвучить. иначе она так и будет витать в воздухе. все будут чувствовать, что что-то их смущает, но, помятуя о «сосисках», озвучить её так и не решатся. озвучишь — лишишься сосиски. вот и бегай за ней. Кроме того, если вы сами не верите, что сосиска упадёт вам в рот, люди, окружающие вас, смогут себя ей только тешить. Но мотивации от этого не прибавится.
В погоне за сосисками вам помогут простые инструменты, такие как планирование, код-ревью и рефакторинг. Спланировав всё тщательно, вы будете иметь представления о дате соприкосновения с сосиской. Код-ревью подскажет, не убежала ли сосиска из-под вашего носа, а рефакторинг поможет вернуть сбежавшую сосиску.
Пришел запрос на новую функциональность. Мы его спланировали. Реализовали. Сидим, ждем сосиску. Из-за отсутствия код-ревью мы узнаем о том, что всё, над чем мы трудились многие дни, работает, как минимум, некорректно и не оптимально. А за отсутствия рефакторинга мы будем осуждены на вечные скитания по баг-трекинговой системе и коду в поисках того самого, последнего бага, за которым покоится сосиска. Но, как нам всем уже известно, он всегда будет предпоследним.
Тот свет
Проверяйте свои vital signs ежедневно. Купите себе тонометры, тахометры, пульсометры, осциллографы, и всё что может помочь в этом, и используйте по назначению. При отсутствии признаков жизни с вашей стороны, сосиска достанется другому. Ваш проект должен хотя бы шевелиться, чтобы вы смогли его закончить. Если же пациент больше мертв, нежели жив (как у Филиппа Дика), то вам поможет только Убик. Либо хиромантия. Либо спиритизм. Всё, что может помочь общаться с теми, кого с нами уже нет. лучше предупредить, чем разбираться с последствиями.
И пусть ваш проект живет долго. Но не слишком долго живет в разработке.
При написании сего поста ни одного менеджера не пострадало. Слова «должен», «обязан» относятся к эвфемическим категориям, и реальны исключительно в моей «параллельной реальности».
и, да… забудьте обо всем, что я написал, если ваши программисты пишут идеальный код.
