Об управлении программистами

Настоятельно советую, всем начинающим руководителям интернет-проектов, да в принципе и не только интернет, прочитать ниже приведенную статью Игоря Ашманова "Правила Ашманова. Часть 1". Я её размещаю в немного урезанном варианте, но со своими комментариями. Полный вариант вы можете прочесть, здесь. Да, вы спросите почему начинающим, да в принципе не почему, просто руководители с опытом более 2-х лет, подобные правила могут составить уже самостоятельно :)

Правило 1. Не бывает технических проблем. Бывают только человеческие, то есть организационные.

Я не даю здесь технических советов относительно управления проектами, правил планирования и документирования, процедур тестирования и выпуска. Обо всем этом написаны горы специальной литературы, в том числе классическая книга Фредерика Брукса "Мифический человеко-месяц".
Однако должностные инструкции и правильные процедуры - далеко не всё. При запуске проекта руководитель в первую очередь вступает в человеческие отношения с коллегами, исполнителями, подчиненными. Эти отношения сложны, непривычны и часто могут просто поставить в тупик, если не знать всего нескольких простых правил.

Как в любом коллективе, так и в коллективе разработчиков, для того чтобы, тебя стали слушать и к твоим словам прислушиваться, а тем более исполнять твои распоряжения, руководитель проектов должен заработать авторитет. Не обязательно быть супер программистом, чтобы тебя стали слушать разработчики. Главное, во-первых выстроить нормальные человеческие отношения, во-вторых, нужно искренне интересоваться вопросами в сфере которых идет разработка, а еще важнее разбираться в них, можно даже не на уровне программирования. В-третьих нужно поступать с разработчиками честно. Давши слово крепись, а не давши держись.

Правило 2. Технический жаргон ничего не значит.

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

Подобный жаргон лучше знать, но стараться общаться именно нормальным языком.

Правило 3. Разработчики всегда называют неверные сроки.
Нельзя верить срокам, которые называют программисты. Обычно их следует умножать на Пи. Иногда (редко) - делить на Пи. Выбор правильного действия руководителя над называемыми сроками зависит от личности разработчика. Это знание приходит к менеджеру только после нескольких экспериментов именно с этим разработчиком.

Ну это распространенная "ловушка", в которую попадает руководитель проектов. И лучше об этом помнить и сроки корректировать исходя из того, что по настоящему реальный срок вам не назовет не один програмист. Опыт и еще раз опыт.

Правило 4. Разработчику свойственен врожденный оптимизм.
Средний разработчик всегда добросовестно заблуждается относительно трудоемкости задачи, обычно в меньшую сторону, поэтому его нельзя уличить или разоблачить. Более того, он никогда не учится на ошибках и постоянно повторяет одну и ту же ошибку занижения сроков, поэтому его бесполезно стыдить или воспитывать. Категорически нельзя рассчитывать, что уж на этот раз битый жизнью разработчик наконец-то называет реальные сроки.
Типичный признак необъезженного разработчика-оптимиста - самоуверенность и горячность, стремление пойти и сделать, а не сесть и запланировать.

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

Правило 5. Программист испытывает страсть к обобщению.
Программист всегда всеми силами стремится сделать работу наиболее общим способом, чтобы потом только настраивать и прилаживать готовую систему. В этом - суть программирования и его сила.
И в этом же - серьезная угроза бизнесу. Если дать разработчику волю, разработка общей платформы отнимет 100% времени и денег, и продукт никогда не выйдет на рынок.
Поэтому программирование в наиболее общем виде нужно категорически запрещать. Верным признаком страсти к обобщению является планирование создания мощных ядер и наиболее общих платформ со сроками исполнения больше года.
Баланс между обобщением и текущими требованиями рынка достигается опытом и соображениями бизнеса. Программистам доверять здесь абсолютно бессмысленно, как бессмысленно обсуждать с пьяницей семейный бюджет.

Четко и максимально понятное и временно отрегулированное ТЗ должно спасти ситуацию.

Правило 6. Нельзя делать "по-хорошему".
Всякий программист свою страсть к обобщению оправдывает похвальным желанием наконец-то всё сделать по-хорошему. Точно так же системный администратор всегда просит денег на самую лучшую технику и самое дорогое программное обеспечение от Oracle. Делать по-хорошему - теоретически неправильно и практически вредно для бизнеса. Нужно делать так, чтобы всё работало, удовлетворяло клиентов (ровно на уровне цены продукта) и бизнес развивался.
Верный признак работы в стиле "по-хорошему" - упорная работа с "ядром", задержки с реализацией конкретной запланированной функциональности и срыв сроков выхода продукта.

Это весьма распространенная проблема и её решение вызывает у программистов жесткий негативизм. Тут только четкий контроль и беседа поможет.

Правило 7. Приминание травы может отнять любое количество времени.
Программист всегда стремится удовлетворить свою потребность в вооруженности - максимально обустроить рабочее место, то есть создать инструментарий, установить самое последнее программное обеспечение, самую современную технику. Если дать ему волю, он потратит на это 100% рабочего времени, причем сумеет доказать начальству необходимость такой работы.
Верный признак такого перманентного обустройства - полуразобранные компьютеры на рабочих местах и необычные, нестандартные программы на этих компьютерах.

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

Выводы
Приходится работать с тем, что есть. Из сказанного вытекает практическая невозможность перевоспитания разработчиков, системных администраторов и средних технических менеджеров в деловом духе. Этого и не требуется. Вместо перевоспитания нужно понимание мотивов и привычек, и работающие процедуры планирования, исполнения и контроля, сохраняющие свободу мышления и оставляющие простор для творчества.
Схемы мотивации также должны учитывать авторские мотивы и врожденный оптимизм разработчика (например, из этого общего принципа легко выводится недопустимость штрафов за срыв сроков).