Общие размышления о целях менеджмента

Опубликовал Слава Панкратов в разделе Библиотека http://www.it4business.ru/lib/1714/
Дата публикации: Январь 13, 2009 в 11:24 pm.

Автор: Алексей Ишков
Источник: sup-executor.livejournal.com

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

Эта истина проста…

Любое коммерческое предприятие создается для того, чтобы приносить владельцам данного предприятия прибыль, а не для того, чтобы у нас была работа.

Ценность любого сотрудника компании, в конце концов, рассматривается с позиции — какую прибыль может принести предприятию деятельность данного индивидуума. По сути своей, владелец предприятия нанимает персонал, чтобы плоды труда каждого из сотрудников принесли ему прибыль от вложенных капиталов. Если менеджмент компании допускает, что кто-то из подчиненных не приносит прямо или опосредованно прибыли в компанию, значит, такой менеджмент неэффективен и должен быть заменен на тот, который осознает эту простую задачу. Совсем даже не ожидается, что каждый рядовой сотрудник компании будет понимать свою индивидуальную задачу в получении прибыли его работодателем, но управляющий им руководитель должен четко помнить конечную цель всех трудов — получение экономической выгоды.

Промышленное производство программных продуктов и Интернет проектов не может быть клубом по интересам. Так называемые «гаражные проекты», как правило, имеют одну общую черту — они создаются энтузиастами, самомотивированными на достижение высоких результатов и поэтому не нуждающимися во внешнем контроле и/или/тем более дополнительном понуждении к достижению успеха проекта. В большом Интернет проекте все далеко не так и на самом деле подчиняется общим правилам ведения бизнеса, ключевыми моментами которых являются управление, планирование и контроль.

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

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

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

Управление, планирование и контроль в разработке программных продуктов и Интернет проектов

К сожалению, программирование — это процесс, который не может быть полностью унифицирован и стандартизирован. Хоть в промышленных условиях, хоть в «гаражном проекте», но в программировании нельзя ввести абстрактный человеко-час, за который можно сделать фиксированное количество кода, функций или процедур. Де факто, программирование займет то время, которое займет, предсказывать его с точностью до минуты бессмысленно.

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

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

В дальнейшем, чтобы на решение задачи не было потрачено больше средств (времени-денег), чем это заняло бы минимально, требуется только контролировать исполнителя, чтобы он не отвлекался на непроизводственную деятельность (вроде чтения ЖЖ). Вот тут и всплывает человеческий фактор или роль личности в истории. У одного исполнителя задача займет 2 часа, у другого та же задача — 2 дня, и оба будут искренне стараться сделать ее быстрее.

Таким образом, вырисовывается, что для снижения издержек на разработку и, следовательно, повышения прибыли проекта руководитель должен:

1. назначать на задачу реальные, обусловленные производительностью данного ресурса, сроки;
2. контролировать исполнителя, чтобы тот не отвлекался на непроизводственную деятельность;
3. выявлять наиболее производительных сотрудников, направляя их на наиболее трудные задания, а менее производительным оставляя задачи попроще;
4. способствовать обучению и обмену опытом между сотрудниками, чтобы менее опытные подтягивались к лучшим;
5. помнить, что хороший человек — это не профессия и непроизводительный подчиненный снижает прибыль на проекте, поэтому с «клиническими случаями» надо расставаться решительно.

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

Детальность планирования, кому она нужна?

Любой тщательно спланированный план рано или поздно разобьется о закон увеличения энтропии во Вселенной. Наиболее близко к нашей действительности эти обстоятельства сформулированы в законе Мёрфи:

Если существуют два способа сделать что-либо, причём один из которых ведёт к катастрофе, то кто-нибудь изберёт именно этот способ.

Из закона Мёрфи в свое время сформулировали семь следствий, каждое из которых нужно учитывать при планировании:

1. Всё не так легко, как кажется.
2. Всякая работа требует больше времени, чем вы думаете.
3. Изо всех возможных неприятностей произойдёт именно та, ущерб от которой больше.
4. Если четыре причины возможных неприятностей заранее устранены, то всегда найдётся пятая.
5. Предоставленные сами себе, события имеют тенденцию развиваться от плохого к худшему.
6. Как только вы принимаетесь делать какую-то работу, находится другая, которую надо сделать ещё раньше.
7. Всякое решение плодит новые проблемы.

Казалось бы, из этого можно сделать простой вывод — планируй, не планируй, все равно иначе будет, тогда зачем?… Делай, что должен, и будь, что будет, так?… Нет, не так. Ответ есть здесь же — следствие номер 5 или иными словами, планирование должно быть просто потому, что без него нас точно ожидает крах.

Планирование — это упорядочивание хаоса в попытке достичь поставленных целей с минимальными потерями.

Нам стоит воспринимать планирование не как четкий маршрут, а как абрис маршрута к известной нам конечной точке. Мы добьемся успеха, только гибко реагируя на противодействие неприятностей, намечая новые шаги и корректируя движение на каждом этапе. Это значит — надо запланировать основные вехи на пути движения и детализировать планы в соответствии с текущими обстоятельствами.

Как планировать, чтобы не промахнуться?

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

При планировании всего процесса разработки в целом руководитель проекта должен:

1. включать в план исполнения сроки с учетом навыков конкретных исполнителей;
2. при планировании сроков под вакантные должности ориентироваться на производительность своих самых слабых ресурсов;
3. включать в общий срок производства 15% времени на форс-мажорные обстоятельства, как то болезни, внеочередные отпуска по семейным обстоятельствам, скоропостижное увольнение сотрудников с соответствующими потерями на найм новых и т.п., можете не сомневаться, они все равно случаться;
4. отдельно включать в план общее тестирование проекта в размере 10% общего времени, запланированного на производство, плюс 10% на исправление ошибок и еще 10% на regression тесты, то есть 30% от времени производства должно быть предусмотрено дополнительно на цикл тестирования-исправления-перепроверки;
5. помнить, что процесс развертывания проекта на боевых мощностях тоже требует существенного времени от 1 дня до рабочей недели, что тоже надо не забыть учесть в плане, иначе рискуем день торжественного открытия проекта назначить на неделю раньше фактической возможности и вот вам рукотворный аврал по собственной непредусмотрительности;
6. планировать более короткие циклы производства-релиза, потому что сейчас уже никто не спорит с тем утверждением, что лучше выпустить на рынок 10 обновлений с последовательным развитием функционала, чем один релиз за тот же срок, но с полным «набором».

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

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

Tags: Career, IT, Management