Разговор двух программистов:
— Что пишешь?
— Сейчас запустим — узнаем!
Количество анекдотов про программистов зашкаливает. Еще бы! Программисты — народ нестандартный, поэтому и подход к ним должен быть особенный. Если волею случая вам пришлось руководить «программистским» проектом, не спешите немедленно приступать к делу, а, вначале изучите особенности общения с представителями этой профессии.
Всю правду и мифы о программистах и их работе собрал воедино Игорь Ашманов – российский менеджер проектов, разработчик компьютерных программ, специалист в области искусственного интеллекта. Всю информацию он записал в форме свода правил, призванного помочь управлять разработчиками.
Правило 1. Технического жаргона всегда можно избежать.
Если ваш программист отдает отчет, написанный сложным и абсолютно непонятным для вас техническим языком, да еще утверждает, что по-другому написать никак нельзя, не верьте ему. По-другому можно и нужно. Все, что вы должны знать о проекте на любом из его этапов, всегда можно выразить обычным деловым языком.
Не исключено, что программисту просто хочется показать свою значимость либо даже свое превосходство над вами — простым смертным, не знающим даже основ программирования. Не позволяйте ему этого. Как руководитель, вы обязаны владеть всей информацией о ходе продвижения проекта, а следовательно, принимать отчеты, составленные на непонятном для вас языке ни в коем случае нельзя.
Анекдот. Настоящий программист никогда не ставит комментариев. То, что писалось с трудом, должно пониматься с трудом.
Правило 2. Программисты не умеют устанавливать сроки.
Если ваш разработчик сообщил, что на выполнение той или иной доработки ему потребуется 2 недели, смело умножайте данный термин на 2. Конечно, бывают редкие случаи, когда термин нужно не умножить, а разделить на 2, но этой скорее исключение, нежели правило. В идеале же следует знать «погрешность» именно того специалиста, которому вы собираетесь поручить задание. Правда, узнать эту самую «погрешность» можно только после нескольких практических экспериментов.
Правило 3. Программистам свойственно преувеличивать свои способности.
Большинство разработчиков не могут правильно определить трудоемкость поставленной перед ними задачи. В результате выполнение задания занимает у них больше времени, чем предполагалось вначале. Причем обвинять программистов в неправильной оценке объемов, как правило, бесполезно — они искренне верят в свои способности и, даже споткнувшись несколько раз, продолжают повторять ту же самую ошибку.
Не думайте, что если программист опытный, то он наверняка четко определит объем работы: даже профессионалами порой руководят самоуверенность и энтузиазм, а не холодный расчет.
Анекдот. Настоящий программист на вопрос: «Можешь ли ты это выполнить?» ответит: «ДА!!!», и только потом подумает, как...
Правило 4. Программисты слишком любят мощь.
Нельзя разрешать программистам самостоятельно планировать конечный объем работ. Их фантазия неуемна, а потому сдержать себя им бывает непросто. Да и думают они в первую очередь уж точно не о бизнесе и не о затратах. Больше всего программистам хочется создать нечто «эдакое» помощнее, а потом уже просто заниматься его наладкой.
Если вы видите, что программист задумал создать мощные ядра и утверждает, что на разработку уйдет более года — тормозите его. Выберите вариант, который отвечает требованиям сегодняшнего рынка — суперзатратные мощности вряд ли себя окупят.
Правило 5. Программисты любят когда все на «высшем уровне».
Программистам всегда хочется закупить самое дорогое оборудование и самое современное программное обеспечение. Но вот с точки зрения бизнеса это обычно не оправдано. Как правило, компании бывает достаточно техники средней мощности.
Нужно приобретать оборудование, которое позволяет выполнять все необходимое для вашего бизнеса и не более. Напрасно переплачивать не стоит, ведь в конечном итоге слишком дорогое оборудование негативно отразится на стоимости выпускаемого продукта.
Правило 6. Программист — это автор, а не бизнесмен.
Программист может интересоваться программой ровно до тех пор, пока не закончит ее разработку и тестирование. После этого он может ее забросить и переключить внимание на что-то новое. Ему не важно, будет ли программа приносить прибыль компании, ему важно лишь заниматься чем-то интересным.
Заставить разработчика поддерживать уже имеющиеся программы бывает непросто, но необходимо.
Анекдот. Если бы архитекторы строили здания так, как программисты пишут программы, то первый залетевший дятел разрушил бы цивилизацию.
Правило 7. Все проблемы вызваны человеческим фактором, то есть неправильной организацией. Технических проблем не существует.
Если вас пытаются убедить, что виновата недостаточно мощная техника, плохие компьютерные программы и т. п. — не верьте. Всегда и во всем виноват человек, который либо допустил ошибку, либо не предусмотрел, как избежать невыгодных ситуаций.
Жизнь и работа программиста овеяна кучей мифов. Вот некоторые из них.
- Разработка ПО — это уникальное направление бизнеса. Нет, разработка ПО — это такой же бизнес, как и производство продуктов питания или косметики. Он существует и развивается по тем же законам.
- Программирование — крайне сложная наука. Нет, процесс разработки ПО не сложнее, чем процесс разработки нового авто или нового фармацевтического средства.
- Программист — это оракул. Программист, это всего лишь «инженер» компьютерных технологий, а не управляющий и не руководитель. А потому полностью полагаться на его мнение и тем более позволять программисту самостоятельно принимать важные решения ни в коем случае нельзя. Да, программист — это образованный человек, который свободно владеет непонятной многим людям терминологией и занимается сложной умственной работой, но... Вспомните, как часто он неправильно называет сроки, не говорит о реальном положении вещей, делает не совсем то, о чем его просили.
- Новые технологии способны «озолотить». Новая технология далеко не всегда становится востребованной. Нередко она не окупает вложенных в нее средств. Успех проекта зависит не от технологий, а от манеры ведения бизнеса.
Как вы уже поняли, к разработчикам требуется особый подход. Перевоспитывать их сложно, да и не нужно. Вполне достаточно понять их привычки и мотивы и создать такую атмосферу в проекте и такой порядок, при которых работа будет выполняться так как нужно вам, но и свобода программистов не сильно пострадает.