Мастерская бизнес-анализа

И снова Сергей Архипенков

26.01.2010 at 19:29 Оставьте комментарий

Статья «Психология управления программными проектами», написанная в жанре эссе, опубликована   в  Сентябре  2009 года и предлагается читателям на главной странице портала для ИТ менеджеров в рубрике «Выбор редакции».

На собственном сайте Сергея  Архипенкова   эта статья была обозначена 2004г., а опубликована на citforum.ru  

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

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

Статья эта большая и читается не просто, поэтому я позволю себе привести некоторые мысли ее автора, которые вызвали отклик лично во мне.

Начало статьи С. Архипенкова:

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

О чем и зачем

Почему эссе? Потому, что этот материал на достаточно частную тему – психологические аспекты управления программными проектами. Потому, что трактовка рассмотренных вопросов отражает субъективный опыт автора и не претендует на полноту.

Для чего написана эта статья? Для того чтобы обнародовать еще одну попытку ответить на традиционные для России вопросы: «кто виноват?» и «что делать?». Вдруг кто-нибудь еще не знает правильных ответов?

Кто виноват в том, что, спустя 30 лет после объявления «кризиса программирования», компания Standish Group, проанализировав работу 364 американских корпораций и итоги выполнения более 23 тысяч проектов, связанных с разработкой ПО, в своем докладе с красноречивым названием «Хаос» пришла к следующим неутешительным выводам.

«Только 16,2% проектов завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности; 52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме; 31,1% проектов были аннулированы до завершения. Для проектов, которые завершились с опозданием или были аннулированы до завершения, бюджет среднего проекта оказался превышенным на 89%, а срок выполнения — на 122%»?

Что делать, для того, чтобы, все-таки, производить необходимые программные продукты с удовлетворительным качеством и в приемлемые сроки?

Начну сразу с ответов.

Кто виноват? Никто. Как никто не виноват в том, что на небе тучи, что идет дождь, что дует ветер. Поскольку самого-то кризиса не было, и нет, а есть лишь Богом данная (для атеистов — объективная) реальность, которая заключена в особой специфике производства программ, по сравнению с любой другой производственной деятельностью. И с этой спецификой мы обязаны считаться, если, конечно, не хотим «дуть против ветра».

Что делать? Управлять людьми. Успех, а равно и провал, проектов по производству ПО на 100% лежит в области психологии.

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

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

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

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

«Вспоминается работа в НИИ, когда рабочие столы в комнате стояли настолько плотно, что расстояния между столами устанавливались с учетом индивидуальных особенностей комплекции каждого работника.»

Мы в лаборатории АСУ1 в 70-е годы сидели точно также плотно: в стандартной прямоугольной комнате столы стояли в 4 ряда: за двумя крайними люди сидели лицом к стене, за двумя средними – лицом друг к другу. И каждый соприкасался стулом с соседом «сзади». Вставли обычно вдвоем – одному встать и не помешать соседу сзади было невозможно. При этом, не было ничего, позволяющего как-то отгородиться (сейчас даже в тесноте все-таки можно спрятаться за монитор компьютера). При этом,  в этой   же комнате сидел не только заведующий лабораторией (Трахтенберг С.Ф.), но и заведующий отделом (Воробьев А.В.)

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

Подтверждаю, работает. В 70-е годы именно так работал Семен Фридрихович. Он сам не был программистом, хотя в премудростях программирования того времени разобрался довольно быстро. И именно так он вместе с программистами искал и находил их ошибки.

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

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

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

Лучше не скажешь. В разных ситуациях я была свидетелем попытки формализации методов и систем оплаты труда специалистов по проектированию АСУ. Много читала об этом. И тоже считаю, что гораздо лучше мотивировать специалистов (всех, а не только программистов) на творческую и заинтересованную работу, чем изыскивать способы формализации. Это попытка руководителя переложить с себя ответсвенность за работу коллектива, и попытка не очень конструктивная.

«Главная цель управления проектом — вызвать у заказчика чувство удовлетворения. Степень удовлетворенности – субъективная величина, которая является отношением субъективной оценки достижений к субъективной же оценке ожиданий или потребностей. Отсюда следует: Продавайте свой проект от начала до завершения работ.

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

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

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

И этот тезис –  необходимость умения работать с заказчиком так, чтобы он был удовлетворен (независимо от того, на какую сумму заключен контракт), но и при этом владеть инструментами убеждения заказчика в случаях, когда он своими замечаниями может нанести вред проекту – полностью совпадает с моими подходами.

Ну и возможно главное, о чем я сильно задумалась, читая эту статью:

«Факт 5. Аутист-шизоид – наиболее распространенный среди программистов тип личности. Мы, программисты, все немного шизоиды.

Аутизм это не болезнь! Мы просто не такие как остальное большинство, которое не готово сутками проводить время за мониторами компьютеров и получать от этого удовольствие. И, пожалуйста, не надо нас лечить и переделывать! Это удача для человечества, что рождаются аутисты. Так, по результатам исследований процент гениев (то есть людей, способности которых существенно выше средних) среди людей с диагнозом “аутизм” достигает 20%. В то время как среди так называемых “нормальных” людей он не превышает 0,001%.

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

Это утверждение относится только к программистам или к аналитикам (разным) тоже?

Вот так я  о нас – специалистах в области ИТ — никогда не думала. Но может быть гуру управления проектами прав и в этом?

Надеюсь, что те, кто прочел мои выдержки с комментариями, прочтут и статью целиком.

Entry filed under: Обзоры.