Я часто слышал как исполнители «ругали» менеджеров, с которыми они работали или работают, но при этом в первую очередь именно исполнители оказываются не готовы к диалогу.
Мы в Qsoft, имея опыт работы с очень крупными клиентами, наверное, находимся в еще более стесненных условиях, когда «приказы не обсуждаются, а исполняются». Однако, чтобы процесс работы был продуктивен и полезен для обоих сторон, мы пытаемся своего менеджера «воспитывать», учить четче формулировать задачи, яснее излагать требования высшего руководства и многому другому.
Наша позиция в этом вопросе нашла отклик среди менеджеров и их руководителей, а мысли, которые за долгое время так или иначе звучали в диалогах, мы решили в итоге отразить как свод советов для менеджеров. Еще чуть позже это разрослось до отдельного проекта, который мы поддерживаем на сайте и на нашей странице в Facebook.
Итак, некоторые советы:
Часто кажется, что удобство пользования это просто вопрос вложенных средств, что удобство можно «купить». Если бы это было так, нас бы окружали сплошь удобные вещи и сайты, а удобство не было бы конкурентным преимуществом. Но, к сожалению, лишь немногим удается в этом преуспеть. Удобство, это скорее кропотливый процесс и внимание к мелочам, чем одноразовое вложение.
Не стоит забывать, что подавляющее большинство сайтов это скорее газета, а не глянцевый журнал. Сайты не смотрят, а читают, а значит самое главное это текст — его подача, верстка и навигация. Утверждая дизайн, не забудьте прочесть то, что будет написано на макете
Качество менеджера это зачастую функция опыта. А лучший опыт — собственные ошибки. Лучше дать менеджеру пару раз ошибиться, чем постоянно делать за него его работу.
Проектирования всегда будет недостаточно. По большому счету, это нормально. Важно умело сочетать работы по постановке задач с их реализацией, декомпозируя проект на как можно меньшие подзадачи и этапы. Чем меньше задача, тем больше шансов ее корректно спроектировать.
Иногда перед менеджером стоит дилемма, что выбрать — сроки или качество. Что лучше — запустить вовремя или отложить релиз, но подойти к этому тщательнее? Каждая ситуация, конечно, индивидуальна, но приоритет лучше отдавать срокам. Как правило, только релиз обнажает истинные проблемы продукта и в итоге позволяет достичь нужного уровня качества.
Если заказчик отказывается принимать участие в проектировании и приемке работ, если он хочет просто выдать задание и получить результат, то лучше всего отказаться от такого проекта и заказчика. А если не получается, то принять на себя всю полноту ответственности, стать заказчиком, и положиться на случай.
Работа менеджера проекта, это прежде всего работа с людьми. Лучшее обучение для менеджера это то, что поможет ему лучше чувствовать и понимать своих коллег, расширять кругозор и уметь посмотреть ситуацию со стороны. Проще говоря, курсы по рисованию могут принести больше пользы, чем тренинг по управлению персоналом.
Любые формы премирования хорошо работают только тогда, когда есть очевидная связь между усилиями премируемого и поставленным KPI. К сожалению, на работу программистов влияет так много факторов, что от них зависит не так много. Поэтому премии плохо работают для программистов.
С одной стороны, лучше когда менеджер разбирается в вопросе, с другой, его знания могут мешать адекватно оценивать ситуацию и мнение специалистов на проекте. Как лучшие директора институтов получаются из посредственных ученых, так и лучшие менеджеры это выходцы из средненьких разработчиков.
Многие часто думают, что статистику главное собрать, но на самом деле, ценность представляют только результаты ее обработки. Грязных данных для обработки всегда слишком много, а результатов и выводов всегда не хватает. Старайтесь концентрироваться не на сборе статистики, а на ее обработке.
Есть базовое правило менеджера проекта, которое применимо почти в любой критической ситуации — декомпозируй и уменьшай задачу. Вероятность что задача или проект будут провалены в силу различных причин прямо пропорциональна их размеру. Поэтому, чем меньше задача — тем больше шансов на успех.
Когда перед менеджером встает задача обеспечить высокую надежность развивающегося проекта, то оказывается, что в подавляющем большинстве случаев это упирается в культуру работы с изменениями, в «отгрузки» нового функционала. Чем тщательнее тесты и сложнее процедура отгрузки, тем меньше проблем с надежностью. Но это удорожает и замедляет разработку. Поэтому всегда приходится выбирать — либо изменения, либо надежность.
Заказная разработка — это, прежде всего, услуга. Тут нет привычного треугольника «сроки-цена-качество», а есть ожидания Заказчика. Важно управлять этими ожиданиями, понимать их. Иногда эти ожидания не имеют ничего общего ни со сроками, ни с качеством, ни с ценой.
Плохой менеджер не любит планерки с разработчиками. На этих планерках, нужно вникать в задачи, отвечать на вопросы, на этих встречах часто вскрываются ошибки менеджера на прошлых стадиях. Куда проще, просто поставить задачу в разработку, и думать что оно само как-то сделается.
Управление проектом — это во многом управление рисками. Всегда есть не нулевая вероятность, что проект будет провален (читай, окажется вне ожиданий Заказчика) — вероятность такого провала определяется вероятностью реализации того или иного риска. Задача менеджера управлять этими рисками, принимая те или иные меры для их купирования (уменьшения вероятности возникновения или возможных последствий).
Часто жизнь проекта начинается задолго до момента начала разработки. Крайне желательно перед тем как брать проект в работу, организовать системную процедуру передачи знаний — некий бизнес-процесс «старт проекта». В рамках этой процедуры нужно выявить скрытые и недокументированные ожидания и риски на проекте.
Если вы хотите организовать какое-либо исследование, например, a/b тест, важно выполнить все условия репрезентативного исследования (правильно выделить исследуемую область, исключить влияние других факторов, обеспечить релевантную выборку). В большинстве случаев это бывает либо очень сложно, либо очень трудоемко и не стоит того. Поэтому, подумайте — готовы ли к тестам, или проще довериться интуиции.
Недостаточное т.з. или проектирование бесполезно, избыточное бессмысленно, так как стоит дороже реализации. Плохое т.з. это подробное описание банальностей, а хорошее сконцентрировано вокруг задач, содержащих наибольшие риски. Лучше получается, если начинать писать т.з. по принципу отрицания, отвечая на вопрос, «чего в системе или функции не будет?», а уже потом уточнять реализацию.
Иногда запуск проекта требует определенной решительности со стороны Заказчика. Остерегаясь неудачи, или несоответствия результата взятым ранее на себя обязательствам, Заказчик может начать откладывать релиз, добавляя новые функции, без которых, как ему кажется «запускаться нельзя». Это опасная для проекта ситуация, когда менеджеру надо помочь Заказчику, а возможно и разделить с ним ответственность.
Помимо производительности команды, важно учитывать и предел некомпетентности — который определяется по наиболее сильному участнику. По мере приближения к этому пределу производительность стремится к нулю. За пределом некомпетентности упорство и труд уже не помогают.
Оригинал: https://www.facebook.com/qsoft.ru
Проведите конкурс среди участников CMS Magazine
Узнайте цены и сроки уже завтра. Это бесплатно и займет ≈5 минут.