Введение
Данная статья впервые была опубликована в журнале «IT Спец» за сентябрь 2007 года. Написана, тем не менее, она была на полгода раньше под впечатлением от работы автора в различных it – проектах, связанных, так или иначе, с разработкой ПО для мобильных устройств. Спустя почти 2 года нельзя не отметить, что материал статьи не потерял своей актуальности. Человеческий фактор как не учитывался при постановке процесса разработки в отечественных компаниях, так и не учитывается.
Вряд ли для кого-то из читателей не очевидно, что рынок информационных технологий в России развивается пугающе быстрыми темпами. Это видно хотя бы по тому количеству проектов, которые растут как грибы после дождя после повсеместного внедрения сотовой связи и развития рынка мобильных устройств. Различные софтверные компании, а также частные предприниматели ринулись осваивать непаханое поле разного рода сервисов, предназначенных для, так называемых, мобильных пользователей. Здесь и контент-сервисы, GPS – системы, средства доступа к различным распределенным системам через мобильное устройство, и т.д. Вместе с тем можно наблюдать открытие все большего числа оффшорных представительств различных западных IT – компаний, ставящих перед своими российскими подразделениями задачу в определенный срок разработать новый сервис, либо программный продукт. Стремительно также развивается рынок корпоративных программных систем и ПО, предназначенного для использования в интересах информационной поддержки малого и среднего бизнеса.
В целом и общем, можно сказать, что рынок информационных технологий осваивается на нескольких фронтах, на каждом из которых имеют место конкуренция, требования к качеству выполнения работ и адекватным срокам разработки.
Все эти проекты объединяет потребность в грамотном менеджменте. Сегодня много говорят и пишут о дисциплине «Управление проектами». На эту тему издаются книги, пишутся статьи, читаются курсы в бизнес-школах, да и вообще нельзя сказать, что в этой области имеет место быть информационный вакуум. Тем не менее, согласно широко известным данным авторитетных исследователей Демарко и Листера, примерно половина IT – проектов либо терпит полный крах, либо заканчивается с бОльшими, чем ожидалось, затратами. Тут важно учитывать тот факт, что эти данные получены в США, где технологии развития IT-проектов совершенствуются уже на протяжении четвертого десятка лет. Если транспонировать эту статистику на российскую действительность, то картина окажется еще более удручающей. Тут также стоит учитывать некоторую специфику именно проектов в сфере информационных или, если угодно, высоких технологий, которая во многом обуславливается отличием подходов к организации работы коллектива программистов по сравнению с коллективом работников других специальностей.
Управление IT-проектом
Что есть «Управление IT-проектом» с точки зрения IT - менеджера? Если обобщить, то это – комплекс мер и действий, призванных обеспечить реализацию продукта/услуги в установленные сроки и с выполнением выделенного бюджета. При этом сам «IT-менеджер» - это либо, так называемый, technical leader, как принято говорить в оффшорах, либо технический директор, либо вообще вице-президент по развитию продукта, как это принято в маленьких венчурных компаниях. О самих «мерах и действиях», включающих в себя предварительное планирование, разработку требований, формирование бюджета и другие технические аспекты деятельности управленца написано множество книг (см. врезку). Данная статья же посвящена одному из наименее освещенных, но при этом одному из важнейших факторов, влияющих на успех проекта и его команды – человеческому. Важность учета человеческого фактора (ЧФ) при формировании группы разработчиков, а также в руководстве ими в сфере IT обуславливается большим влиянием отношения сотрудников к работе на, собственно, результат этой работы.
Особенности формирования команды разработчиков
Предположим, что нам необходимо действовать от лица IT-менеджера, отвечающего за реализацию инновационного проекта. Для большей убедительности излагаемого материала представим, что данный проект является ключевым для компании, и от него зависит ее дальнейшее существование. Такая ситуация, конечно, нереальна для крупных IT-компаний и оффшоров, занимающихся разработкой целых серий продуктов, но зато вполне свойственна небольшим стартапам и венчурным проектам, ориентированных на продажу существующей уникальной услуги. Примерами могут служить Skype, мобильное телевидение, онлайн-игры, сайты знакомств с возможностью оплаты разного рода услуг, сайты-клоны известного Facebook (facebook.com) и пр. Все эти проекты объединяет то, что цель ведущих их компаний не разработка сама по себе с последующей продажей получившегося продукта, а извлечение выгоды из широкого, частично или полностью бесплатного использования продукта пользователями. При этом очевидно, что нет услуги – нет заработка, а в отдельных случаях нет услуги – есть долги. Для реализации подобных проектов часто привлекаются сторонние инвестиции, которые нужно отработать в жесткие сроки. Таким образом, ответственность и давление на человека, отвечающего за реализацию услуги весьма нешуточные. В рамках темы статьи логично было бы попытаться описать какими конкретно чертами должен обладать руководитель разработки вообще и в венчурных проектах в частности, но на эту тему существуют классические труды, которые хорошо себя зарекомендовали (см. врезку). Рассмотрим вместо этого основные принципы формирования команды разработки.
Очевидно, что главным требованием к персоналу является его способность выполнять поставленные задачи. Как ни странно, это часто порождает проблему, поскольку, как правило, команды формируют только исходя из технической компетентности отдельных ее участников. При этом персонал воспринимается на уровне функциональных блоков, то есть обезличенно. Большее внимание уделяется индивидуальным способностям к работе каждого из членов команды, чем потенциальной совместимости с остальными, что часто приводит к проблемам. В классической работе Б. Лаканпала (B. Lakhanpal) были опубликованы результаты исследований более 30 команд разработчиков, показывающие, что на общую производительность команды влияет ее сплоченность, а не индивидуальные возможности ее участников. Грубо говоря, это означает, что на эффективность и продуктивность работы влияет атмосфера в коллективе. Это вовсе не значит, что для достижения максимального результата работы сотрудники должны иметь одинаковые увлечения, либо совместно травить анекдоты в курилке или ходить по злачным заведениям, но в целом и общем следует стараться поддерживать миролюбивую атмосферу. Достигаться это может разными способами, но отдельно стоит выделить мнение авторитетного исследователя проектных групп Терезы Амабайл. В одной из своих работ она пишет, что идеальной рабочей группой является группа людей, которых отличает одновременно как готовность к взаимодействию, так и неоднородность знаний и взглядов. Связано это с тем, что в коллективах, состоящих из людей с разной интеллектуальной базой и разными подходами к работе, предлагаемые идеи часто складываются в интересные и эффективные решения. При этом, как уже упоминалось, необходимым условием успешного функционирования такой группы является интерес к проекту внутри команды, возникновению которого благоприятствует как раз взаимовыгодное с точки зрения получения знаний и опыта сотрудничество участников группы разработчиков.
Неплохая книжка по управлению проектами и мотивации сотрудников
Внутренняя и внешняя мотивации
В общем случае процесс разработки программного обеспечения отличается от, к примеру, процесса сборки автомобиля отечественного автопрома тем, что конечный результат первого во многом зависит от мотивации разработчика. Это поистине неисчерпаемая тема для написания, как минимум, кандидатской диссертации. Найти правильный подход к программисту – задача весьма нетривиальная и требует недюжинных организаторских способностей. При этом выделить можно два типа мотивации:
• Внешняя мотивация – мотивация посредством материальных благ (денежная премия, выделение служебного автомобиля, помощника и т.д.)
• Внутренняя мотивация – получение удовлетворения от работы, приобретение новых профессиональных знаний, удовольствие от общения с людьми
Если первый тип мотивации предельно понятен и повсеместно используется, то внутренняя мотивация гораздо менее очевидна. Принцип Терезы Амабайл гласит: люди работают наиболее эффективно в том случае, если ими движут интерес, удовлетворенность и осознание значимости работы в целом, а не под нажимом внешних обстоятельств. Данный принцип подтверждается и практикой. Автору данных строк довелось работать в венчурной компании, которая занималась предоставлением высокотехнологичного сервиса пользователям с использованием программного обеспечения, которое требовало значительной доработки. Несмотря на высокий потенциал проекта и интерес к нему разработчиков на начальном этапе, руководству компании удалось организовать работу отдела разработки так, что вместо развития существующего сервиса, программистам приходилось интегрировать в систему чудовищные и идущие в противоречие с архитектурой системы программные костыли, единственным назначением которых была презентация, якобы, полнофункциональной системы перед потенциальными партнерами компании и извлечение сиюминутной выгоды. В результате вместо создания полноценного продукта разработчикам пришлось на протяжении неадекватно долгого времени поддерживать этот набор костылей, выслушивая при этом критику от людей, не ознакомленных со спецификой процесса разработки в данной компании. В результате ни высокие зарплаты, ни свободный график работы не смогли удержать ключевых для данной компании разработчиков, которые просто нашли себе новые места работы, где были более благоприятные условия для реализации своего потенциала, а главное, где их работа приносила осмысленный результат.
Способы стимулирования внутренней мотивации
Во многом на внутреннюю мотивацию влияет отношение руководителя отдела разработки к подчиненным. В идеале руководитель должен обладать полной информацией о возможностях и интересах сотрудника. Это позволяет при распределении заданий между разработчиками добиваться максимальной заинтересованности сотрудника в выполнении задачи – она должна быть достаточно сложной, чтобы человек не почувствовал скуки, но не настолько трудной, чтобы он ощущал свою беспомощность. При этом, в идеале, задача должна лежать в сфере интересов разработчика. Именно такая мотивация должна быть основополагающей, поскольку создание программного продукта, несмотря на явную конкретику деятельности, является процессом творческим. Поэтому именно внутренняя мотивация сотрудника приносит большие плоды, чем внешняя.
Нередко случается так, что один или несколько членов команды разработчиков выступают с предложением, направленным, на их взгляд, на улучшение качества продукта, либо на достижение большей прозрачности процесса разработки. Максимально грубой ошибкой, которую может в данном случае допустить менеджер, отвечающий за курирование разработки – это скептическая, либо негативная реакция на предлагаемые инновации. Тем не менее, это болезнь многих менеджеров, причины которой лежат в психологическом ощущении, что критический подход ко всему новому делает их умнее в глазах подчиненных и начальства. При этом помимо отбрасывания потенциально полезных инноваций имеет место сокрушительный удар по внутренней мотивации сотрудников, что в конечном итоге негативно сказывается на качестве их работы. Это не означает, что следует принимать во внимание все предложения группы разработчиков, которая тоже может руководствоваться внутренними мотивами, идущими в разрез с интересами компании, но в таких случаях руководителю определенно нужно быть как можно более дипломатичным.
Возможные проблемы
Одной из важнейших задач, стоящих перед руководителем процесса разработки является организация конструктивного диалога с заказчиком. Это характерно, в основном, для венчурных компаний и небольших стартапов, в которых разработка продукта является необходимым условием существования проекта и получения прибыли. При этом под конструктивным диалогом в данном случае понимаются условия работы, в которых заказчик последовательно видит адекватные результаты разработки с одной стороны, а с другой – разработчики не подвергаются излишнему давлению. Поскольку перед работодателем зачастую стоит задача максимально быстро заработать на услуге и, возможно, погасить свои финансовые обязательства перед инвесторами, то часто возникают перекосы, выражающиеся в постоянных требованиях к разработчикам работать быстрее и больше с одной стороны и в изменениях в требованиях к продукту - с другой. Подобная ситуация может показаться дикой для крупной софтверной организации, но при этом весьма свойственна для небольших динамично развивающихся компаний, которые во многом способствуют формированию рынка. Задача менеджера в такой ситуации – не допустить деморализации команды под воздействием прессинга, поскольку навязанный груз ответственности и рваный ритм благоприятствуют развитию разного рода конфликтов. Внутренние распри, интриги и сплетни, порождающиеся в таких условиях, препятствуют эффективности разработки, поскольку отвлекают персонал от работы и без того отягченной постоянной необходимостью вкалывать на пределе. Чувство общей цели, воодушевление, играющие важную роль для внутренней мотивации немыслимы, если в организации начинается междоусобная борьба и появляются враждующие группировки.
В контексте междоусобных войн необходимо учитывать такую вещь как амбиции. В бурно развивающихся проектах не редки ситуации, когда рядовой разработчик при определенном стечении обстоятельств может быстро продвинуться по карьерной лестнице в рамках конкретной компании. Такая возможность имеет как положительные черты вроде заинтересованности сотрудника в положительных результатах своей работы, так и отрицательные. Каким будет результат зависит от конкретного человека. В процессе реализации упоминавшегося здесь проекта был случай, когда в переломный момент смены технического директора на должность рядового разработчика пришел человек, который, видя потенциальную возможность стать новым руководителем отдела разработки, решил ее не упускать, воспользовавшись ситуацией. На протяжение полутора месяцев он постоянно держался на виду у топ-менеджмента, при любой возможности стараясь завести с ними разговор на отвлеченные темы. При этом в течении этих полутора месяцев в качестве разработчика он не добился абсолютно никакого положительного результата, создав себе по ряду причин отрицательную репутацию. Как ни странно, топ-менеджмент принял в корне ошибочное решение назначить его руководителем, что вызвало волну конфликтов и подковерных игр, в результате которых с поста его сняли, но при этом группа разработчиков окончательно разругалась и деморализовалась.
Увы, такая ситуация не редкость, от нее сложно застраховаться, как и от текучки кадров, которая свойственна стартапам, переходящим из состояния разработки с нуля в состояние поддержки и развития. Здесь подводным камнем может оказаться скептическое отношение программистов к чужому коду. Часто бывает, что при возникновении необходимости модернизации продукта, либо функционала, написанного другими разработчиками, ответственный за выполнение задачи программист заявляет, что код нужно существенно переработать. Не стоит во всех случаях идти на поводу и срывать сроки сдачи проекта, перерабатывая архитектуру. Нужно учитывать скрытые мотивы, свойственные конкретному человеку. К примеру, разработчик может просто бояться, что не разберется в существующем коде, но это не значит, что код некачественный. Когда разработчики не готовы признать свою некомпетентность, они имеют обыкновение выискивать высокоинтеллектуальные оправдания своему бездействию.
Национальные особенности разработки
Многим разработчикам, как и большинству русских людей свойственен такой порок как лень. Это зачастую приводит к тому, что выполнение заданий откладывается на последний момент. Естественно, как правило, оказывается, что эти задания требуют несколько большего времени, чем думалось раньше, и, в результате, сроки сдачи задерживаются. Этот факт еще раз подтверждает важность влияния внутренней мотивации на успехи проекта, поскольку лень можно победить только двумя способами – заинтересованностью сотрудника в проекте, либо угрозой увольнения/штрафа. При этом последний вариант обычно не работает в IT-компаниях, поскольку, как раз отрицательно сказывается на настроениях разработчиков.
Заключение
Вообще говоря, довольно сложно дать универсальные рекомендации по учету человеческого фактора при работе над IT-проектом. Но тем не менее очевидны следующие постулаты:
• Нельзя относиться к сотрудникам как к функциональным единицам. Это в первую очередь люди. А к людям нужен подход.
• Разработчики должны ощущать важность своей работы, тогда они будут относиться к ней более ответственно и заинтересованно
• Первоочередной должна быть внутренняя мотивация, а не внешняя. В условиях, когда зарплата разработчика выше среднерыночной даже в 1,5-2 раза, но при этом отсутствуют нормальные условия работы и интерес к ней, эффективность разработки мала.
• Отношения в команде разработчиков могут быть дружеским, может присутствовать дух соревнования, но никогда не должно возникать распрей и конфликтов. Это крайне негативно сказывается на результатах работы.
• Крайне важно организовать адекватный диалог с заказчиком. Тогда он не будет давить на программистов, а программисты будут понимать что, собственно, от них хотят.
Обязательная к прочтению для любого менеджера книга
