Руководство командой разработчиков программного обеспечения
Прикладные мысли

С. Архипенков

Назад Содержание

Сколько надо платить программисту?

При решении этого вопроса необходимо помнить, что участник команды это не «винтик», как думают некоторые CEO, который можно легко заменить, купив на рынке аналогичный. Я не утверждаю, что программисты незаменимы. Заменимы и еще как. На сегодняшний день средняя текучесть кадров в ИТ составляет по моим оценкам 20–30% в год, однако, отрасль не только не рухнула, но и успешно развивается.

Итак, сколько же надо платить программисту? Как правило рыночная «вилка» вознаграждения для данной квалификации известна, допустим от X до 1.5*X. Можно рискнуть и платить по нижней планке X. Однако, возможность получать в 1.5 раза больше за ту же работу, скорее всего перевесит все остальные стимулы, для удержания специалиста в данной компании. Эта ситуация усугубляется еще и тем, что «охотники за головами» делают разрыв в вилке еще больше, чтобы побыстрее перекупить квалифицированные кадры. Надо ли платить по верхней планке, тем более, если она завышена? А, может быть, следует платить еще больше?

Заранее, приношу свои извинения, за занудность и излишнюю подробность нижеследующего изложения в стиле «как для домохозяек». Сколько раз я не пытался объяснить свое видение подхода к решению этого вопроса людям, которые должны были принимать решение о повышении оклада, они с трудом понимали меня. Может, просто, не хотели?

Программисты заменимы, но у этой замены есть вполне определенная цена (Рисунок 2).

Рисунок 2. Цена замены программиста В.Пупкина на программиста И.Иванова

Определим цену замены программиста В.Пупкина на программиста И.Иванова. Предположим, что Василий успешно работает в вашей компании уже длительное время. Квалификация, опыт и продуктивность его работы постоянно растут, а зарплата, остается на прежнем уровне 2000 у.е. Наконец, Василий оставил вашу компанию в момент Т1, но ваша доблестная кадровая служба в тот же момент (!) на ту же зарплату (!!) нашла ему замену в лице И.Иванова, равнозначную по опыту и квалификации (!!!). Замечу, что это весьма и весьма оптимистичный сценарий.

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

Выполним, приближенную оценку для величины этих потерь. Для этого заменим вычисление площади криволинейной фигуры на вычисление площади прямоугольного треугольника ABC. Найдем катет AB. Сначала найдем величину отрезка между точками Т1 и B. Учтем, что себестоимость единицы рабочего времени программиста складывается из его оклада и накладных расходов (зарплата руководства, уборка, аренда, плата за электроэнергию и проч.). Пусть накладные расходы составляют 200% от зарплаты В.Пупкина. Тогда себестоимость рабочего месяца В.Пупкина составит 6000 у.е. Поскольку, мы рассуждаем об успешном бизнесе, то вправе предположить, что его доходность составляет 25%. Следовательно, компания была должна получать ежемесячный доход от работы Василия, где-то, 7500 у.е. Это е есть искомая длина отрезка между точками Т1 и B. Для того чтобы оценить отрезок между точками А и Т1, предположим, что на начальном этапе адаптации нового сотрудника его коллега с равной зарплатой тратил на помощь ему 20% своего рабочего времени, следовательно компания дополнительно недополучила доход равный 0.2 * 7500 у.е. Таким образом, длина искомого отрезка между точками А и Т1 составляет 1500 у.е. Следовательно, суммарная длина отрезка AB будет равна 9000 у.е.

Величина катета BC = Т2 — Т1, время адаптации зависит от сложности работы, которую делал В. Пупкин и, той роли, которую он играл в проектной команде. Возьмем среднюю величину равную 6 месяцам. Таким образом, по нашей оценке, суммарные потери компании в результате замены Василия составят величину 9000 * 6 / 2 = 27000 у.е., равную площади нашего аппроксимирующего треугольника. И это еще при реализации самого оптимистичного сценария.

Так, сколько же платить? Пусть текущая стоимость квалификации и опыта В.Пупкина на рынке рабочей силы ИТ оценивается вознаграждением от 2000 до 3000 у.е. Очевидно, что при прочих равных условиях вероятность ухода В.Пупкина к конкуренту обратно пропорциональна его доходу, и изменяется от 1.0 до 0.0 в диапазоне рыночных предложений. Если мы не поднимаем Василию зарплату, то с вероятностью, равной 1, компания в ближайшие 6 месяцев недополучит доход на 27000 у.е. Если мы инвестируем в Васю — наш человеческий капитал, и поднимем ему месячную зарплату до 3000 у.е., то он гарантировано останется работать в нашей компании. При этом мы за ближайшие 6 месяцев потеряем только 6000 у.е.

А что дальше? А дальше очередная аттестация и новый пересмотр договора о найме.

Не следует описанное выше принимать как руководство к действию, как алгоритм расчета конкурентоспособной зарплаты ваших разработчиков ПО. Жизнь гораздо сложнее и многообразнее любой модели. Все сказанное выше, следует воспринимать лишь, как подход к тому, как надо думать над вопросом: «Повышать или не повышать зарплату В. Пупкину?»

Стандарт People CMM

Институт технологий разработки программного обеспечения, SEI долгое время работал над совершенствованием процессов разработки ПО. Результатом этой работы явилось создание модели зрелости процессов (Capability Maturity Model, CMM). В качестве дальнейшего развития этой модели институт предлагает модель оценки уровня персонала компании (People Capability Maturity Model, P-CMM), которая может служить основой стратегического совершенствования в управлении человеческим капиталом в организации.

Билл Кёртис один из авторов модели P-CMM в свое время проводил исследование среди разработчиков и выяснил, что соотношение в уровне квалификации между лучшими сотрудниками и специалистами среднего уровня составляет 20:1. Однако, не стоит рассчитывать в коммерческой разработке ПО на команды из суперзвезд. Приходится работать с коллективом людей средних способностей. Но выбор правильной технологии и развитие квалификаций сотрудников позволяет создать команду, которая оказывается очень производительной и добивается прекрасных результатов. Мы собираем людей с коэффициентом мастерства, равным единице, а не 20, но организуем их так, что они обеспечивают очень высокий уровень эффективности работы.

Базовый подход модели P-CMM — это осознание ценности каждого работника как личности и необходимости его дальнейшего развития, что полностью соответствует принципам, изложенными в данной книге.

Подобно CMM, модель P-CMM определяет 5 уровней зрелости компании в части организационного развития и управления персоналом [48].

1. Начальный. Отличается расплывчатостью ответственности, низкой вовлеченностью персонала, отсутствием задачи развития персонала у менеджеров. Работа с кадрами ведется, как правило, без осмысления того, зачем это делать.
2. Повторяемый. Проводится политика, направленная на развитие способностей персонала.
3. Определенный. Внедрение в компании стандартов управления, основанных на лучших практиках работы с персоналом.
4. Управляемый. Определяются и вводятся количественные показатели цели в управлении и развитии персонала.
5. Оптимизируемый. На основе количественных показателей в компании осуществляется непрерывное улучшение процессов работы с персоналом.

Стратегическими целями разработанной модели P-CMM являются:

1. Увеличение эффективности компании путем повышения квалификации персонала.
2. Обеспечение гарантии того, что высококачественная разработка ПО является отличительной особенностью не отдельных работников, а компании в целом.
3. Обеспечение совместимости между мотивацией отдельного сотрудника и мотивацией организации в целом.
4. Сохранение в организации наиболее ценных и эффективных сотрудников.

Внедрение данной модели в полном объеме, а, тем более, получение формального сертификата, на мой взгляд, относятся к области маркетинговой стратегии и потребуют достаточно больших временных и материальных затраты. Если отвлечься от маркетинга, то большинство организаций используют эту модель для грамотного руководства улучшениями в области развития кадров, а не для сертификации. Примером может служить корпорация Boeing [49], где благодаря внедрению практик People CMM уровня 2 удалось существенно снизить текучесть кадров, улучшить процессы управления производительностью персонала и повысить уровень удовлетворенности сотрудников своей работой.

Заключение или Что надо программисту для счастья?

Программист устроен просто. Он состоит из четырех компонентов: тело, сердце, разум и душа.

1. Телу необходимы деньги и уверенность в завтрашнем дне.
2. Сердцу — любовь и признание.
3. Разуму — развитие и самосовершенствование.
4. Душе — самореализация.

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

Работа менеджера проекта подобна труду садовника.

Подобно тому, как садовник любовно отбирает наиболее подходящие растения для своего будущего сада, менеджер набирает людей в команду, наиболее соответствующих целям проекта.

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

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

«Что посеешь, то и пожнешь» — этот закон одинаково применим как к труду садовника, так и к труду менеджера проекта. Пренебрежительное отношение к людям породит лишь ответное пренебрежение. Вложите в людей часть своей души, и вам воздастся сторицей.

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

Литература

1. Jim Johnson. «Chaos: The Dollar Drain of IT Project Failures. Application Development Trends», January 1995. Standish Group.
2. Алистэр Коуберн, Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения, Humans and Technology, Октябрь, 1999 .
3. Стивен Р. Кови, «7 навыков высокоэффективных людей. Мощные инструменты развития личности», 2-е изд., М., Альпина Бизнес Букс, 2007
4. Брукс Фредерик, "Мифический человеко-месяц, или Как создаются программные комплексы", Пер. с англ., СПб., Символ-Плюс, 1999.
5. Кьелл А. Нордстрем, Йонас Риддерстрале, «Бизнес в стиле фанк. Капитал пляшет под дудку таланта», Стокгольмская школа экономики в Санкт-Петербурге, 2005.
6. П. Друкер, «Задачи менеджмента в XXI веке», М., «Вильямс», 2002.
7. А.Маслоу. «Новые рубежи человеческой природы», М., Смысл, 1999.
8. В. Франкл. «Человек в поисках смысла», М., Прогресс, 1990 г.
9. Кэтлин Мелимука, «Разговор с Томом де Марко», Computerworld, #05/1996.
10. Richie O'Bower, «Programming as the best creative specialty», 1997.
11. А. Зубарев «Мифотворцы», 2003 (http://zay-note.blogspot.com/2007/05/blog-post.html).
12. С.Рубинштейн, «Основы общей психологии», СПб, «Питер», 2000.
13. Богомаз С.А., «Психологические типы К.Г.Юнга, психофизиологические типы и интертипные отношения», Томский государственный университет, 2000
14. Гуленко В. В., «Менеджмент слаженной команды», 2003 г., Изд.: АСТ, Астрель
15. Б. Шнейдерман, «Психология программирования», М., Радио и связь, 1984.
16. Отто Крегер, Дженет Тьюсон, Хайл Ратледж Типы людей и бизнес. Как 16 типов личности определяют ваши успехи на работе, М., Персей Вече Аст, 1995 .
17. С.Макконнелл, «Профессиональная разработка программного обеспечения», М., «Символ», 2007.
18. Манфред Кетс де Врис, «Мистика лидерства. Развитие эмоционального интеллекта», М., Альпина Бизнес Букс, 2005
19. Р.М. Белбин, «Типы ролей в командах менеджеров». М., HIPPO, 2003.
20. Игорь Ашманов, «Словарь ненормативной лексики программиста», 2002, (http://www.ashmanov.com/pap/obspro.phtml)
21. M. Pomeroy-Huff, J. Mullaney, R. Cannon, M. Sebern, «The Personal Software Process (PSP) Body of Knowledge», version 1.0, SPECIAL REPORT CMU/SEI, 2005
22. С. Бобровский, «Ошибкам — бой!», PC Week 144 (20), 1998
23. Joel Spolsky, «The Guerrilla Guide to Interviewing», 2000 (http://www.joelonsoftware.com/articles/fog0000000073.html)
24. Аллан Пиз, Язык телодвижений. Как читать мысли окружающих по их жестам, М. Эксмо-Пресс, 2007.
25. Том Демарко, Тимоти Листер, «Человеческий фактор: успешные проекты и команды», Спб. Символ-Плюс, 2005.
26. Harvey, Jerry B. «The Abilene Paradox and other Meditations on Management», Jossey-Bass, 1996
27. Том Демарко, «Deadline. Роман об управлении проектами», М., Вершина, 2006.
28. Л. Томпсон, «Создание команды», М., Вершина, 2005
29. Е. Чинарова, «Team-building, или «Потому что мы — команда!», Журнал «Управление компанией», №3, 2005.
30. О.Платонов «Терновый венец России. История Русского народа в XX веке», Т. I, М., "Родник", 1997.
31. А.Фенько , «Миф о русском коллективизме», Журнал «Власть» №45, 2002 г.
32. Watts S. Humphrey, «The Team Software Process (TSP)», Technical Report CMU/SEI, 2000
33. Higgs, Malcom , «A comparison of the Myers-Briggs Type Indicator and Belbin Team Roles», Henley Management College, 1996
34. Стивен У. Фланнес, Джинджер Левин, «Навыки работы с людьми для менеджеров проектов», М., Технологии управления Спайдер, 2004 г.
35. А. Коуберн, «Каждому проекту своя методология», Humans and Technology Technical Report, TR 99.04, Oct.1999 (русский перевод http://www.maxkir.com/sd/methyperproject_RUS.htm).
36. Том ДеМарко, Тимоти Листер, Вальсируя с Медведями. Управление рисками в проектах по разработке программного обеспечения, М., Компания p.m.Office, 2005.
37. «PMBOK. Руководство к Своду знаний по управлению проектами», 3-е изд., PMI, 2004.
38. Питер Ф. Друкер «Эффективный управляющий».
39. B. W. Boehm, "Theory-W Software Project Management: Principles and Examples", IEEE Transactions on Software Engineering, Vol. 15, No. 7, July 1989
40. Эдвард Йордан, «Путь камикадзе», М., Лори, 2005.
41. Gerald Weinberg, «Psychology of Computer Programming», Van Nostrand Reinhold, 1971.
42. Абрахам Гарольд Маслоу, Мотивация и личность, М., Евразия, 1999 г.
43. С. Степанов, «В поисках человечности. Абрахам Маслоу (1908—1970)», Школьный психолог, № 30, 2001
44. Эд Салливан, «Время — деньги. Создание команды разработчиков программного обеспечения», Русская редакция, Москва, 2002.
45. Фергус О'Коннэл, «Как успешно руководить проектами. Серебряная пуля», М., КУДИЦ-ОБРАЗ, 2003.
46. И. Ашманов, «Правила Ашманова». Часть 2: об управлении проектами, 2002 (http://www.ashmanov.com/pap/ashrul2/)
47. А. Иншакова, Д. Иншаков, ИТ-персонал: оценка, мотивация и развитие, 2007 (http://www.iemag.ru)
48. Bill Curtis, William E. Hefley, Sally A. Miller, «People Capability Maturity Model (P-CMM Version 2.0)», Software Engineering Institute, 2002.
49. Sally Miller, Bill Curtis, and William Hefley, Improving Workforce Capabilities with the People Capability Maturity Model, issue of CrossTalk, April 2003.

Назад Содержание