Откуда брать информацию о рисках

Как отмечается в литературе об управлении, самые опасные риски, это те о которых мы забыли или вообще не знали. Поэтому, первое, что мы должны сделать, приступая к управлению рисками, выписать все возможные риски проекта.

Серьезным поставщиком рисков являются нерешенные проблемы. Даже, если в предыдущем проекте нам удалось как-то выкрутиться, проблема грозит нагнать нас в следующих проектах, и так до тех пор, пока не будет найдено её решение. Поэтому проблемы следует анализировать и решать сразу после их осознания, не дожидаясь, пока они проявятся в самый неподходящий момент.

Чем больше мы знаем о рисках, тем эффективнее можем ими управлять. Источники таких знаний – наш и чужой опыт. У каждого из этих источников есть свои достоинства и недостатки. Чужого опыта много, на его основе можно делать достоверные статистические выводы, но он не учитывает особенности нашей команды, фирмы и тематики. Поэтому необходимо постоянно собирать и систематизировать собственный опыт управления разработками.

Лекция 7. Управление персоналом

А главное, Шарапов, нужно, чтобы люди были тебе действительно интересны.

к/ф «Место встречи изменить нельзя»

Роль персонала в эффективности проекта

Хорошая команда разработчиков может создать выдающийся проект, несмотря на объективные трудности, ошибки администрации, неудачную конъюнктуру и т.д. Однако, в мировой практике не известны случаи, когда команда посредственностей создавала действительно хороший проект.

В середине 80-х годов в США и Австралии проводились эксперименты, целью которых являлись выявление факторов, влияющих на производительность и оценка различий в производительности разработчиков программного обеспечения [1]. В эксперименте участвовали несколько сотен программистских фирм, каждую из которых представляли 2-3 разработчика. Всем участникам эксперимента выдавались задания, которые они выполняли на своих рабочих месте, используя привычные языки программирования, инструментарий и технические средства. Задания подбирались схожими по сложности и по трудоемкости. Результаты и время выполнения заданий фиксировались экспериментаторами.

На основании полученных данных была построена кривая распределения персональной производительности разработчиков (рис. 7.1). На горизонтальной оси откладывалось время, потраченное на выполнение задания, а по вертикали – количество разработчиков, выполнивших задание за указанное время.

Рис. 7.1. Вариации производительности разработчиков программного обеспечения.

Аналогичные кривые получались по результатам нескольких лет наблюдений, проводимых разными экспериментаторами. Лучшие разработчики имели производительность в 2,5 раз выше средней и почти в 10 раз выше, чем аутсайдеры. При этом, если разделить разработчиков на две группы: с производительностью выше средней и ниже средний, то средняя производительность первой группы в 2 раза превышает среднюю производительность второй группы.

В ходе эксперимента выяснилось, что многие факторы, которые мы интуитивно включаем в список существенно влияющих на производительность, на самом деле влияют очень слабо. Рассмотрим эти факторы.

• Язык программирования. Эксперимент показал, что лучшим языком для решения поставленной задачи является язык, который лучше знает разработчик. Исключением является язык Ассемблер, требующий существенно больших затрат усилий по сравнению с языками высокого уровня.

• Стаж разработчиков. Если стаж более двух лет, то он практически не влияет на производительность. Другое дело – опыт: сумма знаний, умений и навыков, приобретенных в прошлых разработках. Но опыт зависит не столько от того, как долго человек работал, сколько от того, как он работал.

• Качество выполнения заданий (количество недочетов). У большинства разработчиков, быстро справившихся с заданием, качество работы было выше, чем у отстающих. Это свидетельствует о том, что при правильной организации работы, качество не приводит к её удорожанию, а если работа организована неправильно, даже дополнительные затраты не смогут повысить её качество.

• Уровень заработной платы. Это неожиданно, но производительность разработчика слабо коррелирует с уровнем его зарплаты. Лучшая половина получала зарплату всего на 10% выше, чем худшая, имея вдвое большую производительность.

Эксперимент выявил ещё одну интересную закономерность: высокую корреляцию производительности разработчиков одной фирмы. Например, если у одного представителя фирмы дело не ладилось, то с большой вероятностью и у другого представителя той же фирмы, дела также шли плохо. Кривая распределения производительности по фирмам оказалась схожей с кривой индивидуальной производительности, изображенной на рис. 1. Складывалось впечатление, что одни фирмы сумели собрать у себя классных специалистов, а другие могли привлечь только аутсайдеров.

Фирмы-лидеры, собравшие лучших разработчиков, приобретают огромное конкурентное преимущество, так как их издержки могут быть значительно ниже, чем у остальных фирм. А фирмы-аутсайдеры попадают в порочный круг: Из-за низкого профессионального уровня и текучки персонала руководство считает нецелесообразным вкладываться в кадры. Это приводит к ещё большей текучке, при этом в первую очередь, фирму покидают наиболее перспективные сотрудники, которым легче найти другую работу. Если фирма действительно хочет стать лидером, она должна разорвать этот круг, постоянно заботится о формировании команды профессионалов, стремиться выпускать продукты, лучшие в своей области.