Управление собственным проектом: работа с программистом, часть 2
Posted on 13/03/2015
95 процентов ошибок исполнителей - это вина менеджера.
Ирина Петровна,
самый суровый преподаватель, которого я видел.
Привет, мой латентный читатель. Я и мой космический кот Орион продолжаем цикл статей на тему ИТ менеджмента. Мы очень рады тому, что немало людей читают мои материалы, что придает мне силы и уверенность в написании новых статей.
За последние несколько месяцев мы наблюдали над самим собой, дабы понять некоторые особенности работы программиста (или другого работника с техническим укладом мышления). Примерно на 3-ем курсе университета я впервые услышал фразу “нематериальные методы стимулирования”. Признаться, она несколько лет подряд не давала мне покоя, пока я не начал всерьез воспринимать психологию в качестве науки, стоящей наравне с математикой.
Думая, что все люди работают только ради денег и других схожих активов, которые можно положить в карман, я ошибался.
Мозг программиста и другой ИТ персоны работает своеобразно, но всё же есть характерные черты, зная которые, можно добиваться эффективной работы в команде.
Пазл как видение трудового процесса
Процесс кодирования воспринимается бОльшей частью человечества как процесс невероятно скучный, свойственный только странным персонажам типа программистам с большими очками и засаленными футболками.
Даже бывалым девелоперам бывает скучно, если каждый день они работают над одним и тем же, не осознавая в какой части большого пути они находятся.
Я сторонник подхода, в котором исполнитель должен быть осведомлен (без лишних деталей) куда и зачем двигается проект. Исполнитель должен видеть как та работа, которую он выполняет, подобна выкладыванию пазла. Каждая “ячейка” служит общей цели, которую исполнитель приближает собственными усилиями. Ячейки должны быть достаточно маленькими, чтобы казаться выполнимыми, но не настолько, чтобы казаться легкодоступными.
Большие задачи менеджер обязан разбивать на мелкие и давать их своих исполнителям.
Единый стиль кодирования
Большинство программистов втайне от самих себя считают свой код лучше, чем тот, который написан другим разработчиком.
Если вы как управленец не хотите, чтобы ваши сотрудники тратили время на то, чтобы переоформить код надлежащим образом (согласно собственным убеждениям), то советую ввести единый стиль кодирования. Например, для проектов на PHP мне нравится то, что предлагают товарищи из Kohana (http://kohanaframework.org/3.3/guide/kohana/conventions).
Если надо, впишите такое требование в трудовой договор или техническое задание проекта. Почему это важно? Ответ прост: если несколько программистов работает над одним и тем же кодом, и они последователи разных стилей оформления кода, то рано или поздно они начнут переписывать код друг друга, а это пустая трата времени, которая вряд ли вам нужна. Кроме того, они почти перестанут замечать разницу между своим и чужим кодом и будут меньше заниматься сравнением себя с другими.
Детерминированность рабочего процесса
Заголовок выглядит довольно заумно, но все достаточно просто.
Технический специалист - это большой любитель точности и определенности. Рабочий процесс в команде не должен прерываться из - за того, что, например, девелоперу нужны тестовый аккаунт в платежной системе или из - за того, что непонятно, как правильно обновить работающую систему, не потеряв обновления, сделанные другими. Менеджер, помни, если ты не обдумал рабочий процесс до таких деталей, то исполнители (программисты) сделают это сами, затратив какое - то время.
Рабочие инструкции
Если вы считаете, что написание инструкций, - это полнейшее занудство и пустая трата времени, то, видимо, вы вряд ли видели действительно растущую компанию. Когда придет волшебное мгновение, и в вашей компании начнут появляться новые люди, то через некоторое время вы удивитесь тому, насколько сильны порой бывают заблуждения работников относительно того или иного процесса.
Большинство вопросов, которые будут возникать у новичков в команде, будут однотипны и, возможно, будут повторяться. А представьте, что у вас уже есть документ (статья, график, модель), который будет отвечать на такие вопросы?! Вам не придется больше тратить время на разъяснительную работу. Достаточно будет только показать, где находятся знания, необходимые для решения той или иной задачи.
Кроме того, рабочие инструкции помогают в случае сильной текучки кадров.
Человеческое лицо менеджмента
Думаю правильным завершать свои статьи чем - то позитивным и либеральным. Например, пожеланием того, чтобы быть человечным по отношению к своим работникам. Менеджер как обладатель тех или иных ресурсов все же остается человеком, который может ошибаться. Эпиграф, используемый мною, - это напоминание об ответственности за принятие управленческих решений. Управленец задаёт вектор движения, все остальное служит лишь вспомогательным механизмом данного вектора.
Сергей Кошкарёв 13 марта 2015 г.