Заметки на полях
14.04.2014 | Автор: Денис Митрофанов, QSOFT (CEO, совладелец) 
Я часто слышал как исполнители «ругали» менеджеров, с которыми они работали или работают, но при этом в первую очередь именно исполнители оказываются не готовы к диалогу.
Мы в Qsoft, имея опыт работы с очень крупными клиентами, наверное, находимся в еще более стесненных условиях, когда «приказы не обсуждаются, а исполняются». Однако, чтобы процесс работы был продуктивен и полезен для обоих сторон, мы пытаемся своего менеджера «воспитывать», учить четче формулировать задачи, яснее излагать требования высшего руководства и многому другому.
Наша позиция в этом вопросе нашла отклик среди менеджеров и их руководителей, а мысли, которые за долгое время так или иначе звучали в диалогах, мы решили в итоге отразить как свод советов для менеджеров. Еще чуть позже это разрослось до отдельного проекта, который мы поддерживаем на сайте и на нашей странице в Facebook.
Итак, некоторые советы:
1Удобство нельзя купить Часто кажется, что удобство пользования это просто вопрос вложенных средств, что удобство можно «купить». Если бы это было так, нас бы окружали сплошь удобные вещи и сайты, а удобство не было бы конкурентным преимуществом. Но, к сожалению, лишь немногим удается в этом преуспеть. Удобство, это скорее кропотливый процесс и внимание к мелочам, чем одноразовое вложение.
2Как не сломать глаза Не стоит забывать, что подавляющее большинство сайтов это скорее газета, а не глянцевый журнал. Сайты не смотрят, а читают, а значит самое главное это текст — его подача, верстка и навигация. Утверждая дизайн, не забудьте прочесть то, что будет написано на макете
3«Опыт, сын ошибок трудных» Качество менеджера это зачастую функция опыта. А лучший опыт — собственные ошибки. Лучше дать менеджеру пару раз ошибиться, чем постоянно делать за него его работу.
4Меньше — значит лучше Проектирования всегда будет недостаточно. По большому счету, это нормально. Важно умело сочетать работы по постановке задач с их реализацией, декомпозируя проект на как можно меньшие подзадачи и этапы. Чем меньше задача, тем больше шансов ее корректно спроектировать.
5Не откладывайте на завтра… Иногда перед менеджером стоит дилемма, что выбрать — сроки или качество. Что лучше — запустить вовремя или отложить релиз, но подойти к этому тщательнее? Каждая ситуация, конечно, индивидуальна, но приоритет лучше отдавать срокам. Как правило, только релиз обнажает истинные проблемы продукта и в итоге позволяет достичь нужного уровня качества.
6И рыбку съесть и кости продать Если заказчик отказывается принимать участие в проектировании и приемке работ, если он хочет просто выдать задание и получить результат, то лучше всего отказаться от такого проекта и заказчика. А если не получается, то принять на себя всю полноту ответственности, стать заказчиком, и положиться на случай.
7Возлюби ближнего своего Работа менеджера проекта, это прежде всего работа с людьми. Лучшее обучение для менеджера это то, что поможет ему лучше чувствовать и понимать своих коллег, расширять кругозор и уметь посмотреть ситуацию со стороны. Проще говоря, курсы по рисованию могут принести больше пользы, чем тренинг по управлению персоналом.
8«Программистов не кормить» Любые формы премирования хорошо работают только тогда, когда есть очевидная связь между усилиями премируемого и поставленным KPI. К сожалению, на работу программистов влияет так много факторов, что от них зависит не так много. Поэтому премии плохо работают для программистов.
9Меньше знаешь — лучше контролируешь С одной стороны, лучше когда менеджер разбирается в вопросе, с другой, его знания могут мешать адекватно оценивать ситуацию и мнение специалистов на проекте. Как лучшие директора институтов получаются из посредственных ученых, так и лучшие менеджеры это выходцы из средненьких разработчиков.
10Данных мало ен бывает Многие часто думают, что статистику главное собрать, но на самом деле, ценность представляют только результаты ее обработки. Грязных данных для обработки всегда слишком много, а результатов и выводов всегда не хватает. Старайтесь концентрироваться не на сборе статистики, а на ее обработке.
11Малая задача — большая удача Есть базовое правило менеджера проекта, которое применимо почти в любой критической ситуации — декомпозируй и уменьшай задачу. Вероятность что задача или проект будут провалены в силу различных причин прямо пропорциональна их размеру. Поэтому, чем меньше задача — тем больше шансов на успех.
12Третьего не дано Когда перед менеджером встает задача обеспечить высокую надежность развивающегося проекта, то оказывается, что в подавляющем большинстве случаев это упирается в культуру работы с изменениями, в «отгрузки» нового функционала. Чем тщательнее тесты и сложнее процедура отгрузки, тем меньше проблем с надежностью. Но это удорожает и замедляет разработку. Поэтому всегда приходится выбирать — либо изменения, либо надежность.
13«Управляй мечтой» Заказная разработка — это, прежде всего, услуга. Тут нет привычного треугольника «сроки-цена-качество», а есть ожидания Заказчика. Важно управлять этими ожиданиями, понимать их. Иногда эти ожидания не имеют ничего общего ни со сроками, ни с качеством, ни с ценой.
14На планёрку становись Плохой менеджер не любит планерки с разработчиками. На этих планерках, нужно вникать в задачи, отвечать на вопросы, на этих встречах часто вскрываются ошибки менеджера на прошлых стадиях. Куда проще, просто поставить задачу в разработку, и думать что оно само как-то сделается.
15Кто не рискует, тот… Управление проектом — это во многом управление рисками. Всегда есть не нулевая вероятность, что проект будет провален (читай, окажется вне ожиданий Заказчика) — вероятность такого провала определяется вероятностью реализации того или иного риска. Задача менеджера управлять этими рисками, принимая те или иные меры для их купирования (уменьшения вероятности возникновения или возможных последствий).
16Запланированный ребенок Часто жизнь проекта начинается задолго до момента начала разработки. Крайне желательно перед тем как брать проект в работу, организовать системную процедуру передачи знаний — некий бизнес-процесс «старт проекта». В рамках этой процедуры нужно выявить скрытые и недокументированные ожидания и риски на проекте.
17Может, на авось Если вы хотите организовать какое-либо исследование, например, a/b тест, важно выполнить все условия репрезентативного исследования (правильно выделить исследуемую область, исключить влияние других факторов, обеспечить релевантную выборку). В большинстве случаев это бывает либо очень сложно, либо очень трудоемко и не стоит того. Поэтому, подумайте — готовы ли к тестам, или проще довериться интуиции.
18Золотая середина Недостаточное т.з. или проектирование бесполезно, избыточное бессмысленно, так как стоит дороже реализации. Плохое т.з. это подробное описание банальностей, а хорошее сконцентрировано вокруг задач, содержащих наибольшие риски. Лучше получается, если начинать писать т.з. по принципу отрицания, отвечая на вопрос, «чего в системе или функции не будет?», а уже потом уточнять реализацию.
19С минуты на минуту Иногда запуск проекта требует определенной решительности со стороны Заказчика. Остерегаясь неудачи, или несоответствия результата взятым ранее на себя обязательствам, Заказчик может начать откладывать релиз, добавляя новые функции, без которых, как ему кажется «запускаться нельзя». Это опасная для проекта ситуация, когда менеджеру надо помочь Заказчику, а возможно и разделить с ним ответственность.
20Уменье и труд не все перетрут Помимо производительности команды, важно учитывать и предел некомпетентности — который определяется по наиболее сильному участнику. По мере приближения к этому пределу производительность стремится к нулю. За пределом некомпетентности упорство и труд уже не помогают.
Полный текст статьи читайте на CMS Magazine
