Правила Ашманова

19.10.06

Управление проектом

Данный свод высказываний предназначен для руководителей, которым волей судеб пришлось заниматься новым для себя делом - управлять тем или иным "программистским" проектом (созданием информационной системы предприятия, разработкой сайта, и т. п.).

Опытному человеку сказанное ниже может показаться набором простых и давно известных истин. Я и не собираюсь претендовать на авторство всех приведенных ниже правил.

Однако начинающие менеджеры программных проектов зачастую не знают простейших вещей - например, того простого факта, что нельзя верить срокам, называемым программистами. Воинские уставы и Правила дорожного движения также выглядят просто, но они "писаны кровью".
Часть I

Артем Попов. © "Ашманов и Партнеры"

Данный свод высказываний предназначен для руководителей, которым волей судеб пришлось заниматься новым для себя делом - управлять тем или иным "программистским" проектом (созданием информационной системы предприятия, разработкой сайта, и т. п.).

Опытному человеку сказанное ниже может показаться набором простых и давно известных истин. Я и не собираюсь претендовать на авторство всех приведенных ниже правил.

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

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

Вот эти простейшие вещи и собраны здесь в виде свода правил. Вот самое первое из них:

Первое правило Ашманова. Не бывает технических проблем. Бывают только человеческие, то есть организационные.

Я не даю здесь технических советов относительно управления проектами, правил планирования и документирования, процедур тестирования и выпуска. Обо всем этом написаны горы специальной литературы, в том числе классическая книга Фредерика Брукса "Мифический человеко-месяц".

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

Об управлении программистами

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

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

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

Распространенные мифы о разработке программного обеспечения

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

Поэтому разговоры об уникальности разработчиков ПО, специфике управления программистским проектом, особых путях бизнеса - всегда очень подозрительны.

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

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

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

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

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

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

Правила, которые полезно знать менеджеру

Правило 2. Технический жаргон ничего не значит.

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

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

Правило 3. Разработчики всегда называют неверные сроки.

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

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

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

Типичный признак необъезженного разработчика-оптимиста - самоуверенность и горячность, стремление пойти и сделать, а не сесть и запланировать.

Правило 5. Программист испытывает страсть к обобщению.

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

И в этом же - серьезная угроза бизнесу. Если дать разработчику волю, разработка общей платформы отнимет 100% времени и денег, и продукт никогда не выйдет на рынок.

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

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

Правило 6. Нельзя делать "по-хорошему".

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

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

Правило 7. Приминание травы может отнять любое количество времени.

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

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

Правило 8. Разработчик не интересуется бизнесом, он - типичный автор.

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

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

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

Выводы

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

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

Перепечатано с письменного разрешения компании "Ашманов и Партнёры"

См. также

10 типовых рисков срывов проекта. Памятка для внедренцев и заказчиков

Кейсы проектов Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    2734    0    1СERP    21    

31

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Кейсы проектов Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    14232    0    ASchekachev    37    

55

Организация работы внутренней команды 1С с помощью Канбан

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    5819    0    stnslv    5    

25

Технология проекта внедрения 1С:ERP – как управлять большим проектом

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    4654    0    andironenko    2    

31

На что похож ваш продукт: на Аквариум или на Муравейник? 

Инструменты управления проектом Бесплатно (free)

Давайте поиграем в метафоры в лучших традициях экстремального программирования. А заодно проведем новогодний конкурс - на лучшую метафору для автоматизированного продукта

27.12.2022    2733    0    MariaTemchina    28    

23

ТРИЗ. Решение нерешаемых проблем в бизнесе

Управление проектом Бесплатно (free)

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    4152    0    user1576201    10    

17

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Бизнес-анализ Управление проектом Команда Управление ИТ Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Цикл статей о том, почему акушер-сантехник широкого профиля - это ПЛОХО. Расскажу плюсы специализации на одной предметной области. Рассмотрим понятные аналогии из других областей. Проанализируем пару вакансий, естественно без указания компании.

09.09.2022    10593    0    biimmap    79    

73

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Архитектура Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    13027    0    Evil Beaver    17    

116
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. 20.10.06 13:48 Сейчас в теме
"Мифы, Правила, которые полезно знать менеджеру"...

Сомневаюсь что кто-либо из менеджеров ИТ найдет здесь для себя что-то новое, хотя бы потому что 90% из них все те же разработчики или программисты, оказавшиеся в силу возложенных на них обязательств по другую сторону "окопа"...

Ну а разработчикам - \"мотайте на ус\"... Мы все про вас знаем ;-)

2. 20.10.06 16:02 Сейчас в теме
И еще:
"Производство программного обеспечения не является особым бизнесом, что бы там ни говорили сами разработчики или продавцы информационных систем. Оно не более особенное, чем пищевая промышленность или косметология. Законы развития и окупаемости проектов при разработке ПО, интернет-сайтов и корпоративных информационных систем - те же самые, что и везде".
М-да... Несколько разъяснений:
Отличительная особенность ИТ проектов это их высокая стоимость и скорость/быстрота устаревания (базовые знания для IT Project Management). Отсюда все следующее:
Хотел бы я увидеть счастливо владельца софтверной компании, выходца из директоров пищевой фабрики в прошлом.
Законов окупаемости ПО на сегодня вобще нет (в отличие от других областей деятельности). Попытки расчета есть, законов - нет. Увы...
3. vakham 19 10.02.17 13:35 Сейчас в теме
Редко комментирую. Но как в анекдоте "я как случайный прохожий, не обязан говорить, но как ответственный гражданин официально заявляю" ...
Бред.

"Не бывает технических проблем. Бывают только человеческие, то есть организационные."
Утрирование до уровня плинтуса. Утрируем до подвала: нет организационных проблем, есть проблема тараканов в голове директора.

"Управлять программным проектом может даже гуманитарий. "
Ипанулись?! Хотя, в стане где министр обороны управлял мебельной фабрикой в 15 рыл...
О да! Мало того, бухгалтерией может командовать главбух, которая не знает "хто формирует субсчета". It's Russia, baby!
Нач.отделами становятся секретутки, вовремя подмахнувшие лысому директору.

"менеджеру достаточно знать некоторые особенности"
Мои рекомендации: ящик пива, чипсы, тёплые тапочки и включаем сериал "Техподдержка" (он же "Компьюторщики").

"Оно не более особенное, чем пищевая промышленность".
Всё смешалось: птицы, двери... Мозг расплылся по стене...

"Миф о величии программиста. "
Падшая женщина! Если заказчик тупо кликает одну кнопку, не понимая что он вообще делает и кому это надо...
То кем является человек, который досканально разобрался в работе двух-трех отделов и десятка "специалистов"-кнопкодавов?
Падшая женщина! Этот крайний во всех бедах, как ни странно, разбирается лучше "специалистов" в конечном итоге.

"Миф о магической силе технологии."
Управление то же сумма технологий. С учётом неумения управлять вообще со стороны "манагеров", сумма технологий похожа на магию.
Канбан, например. Просто магия... шаманство для любого манагера.

"Технический жаргон ничего не значит."
Детородный орган! Программисты должны изъясняться не на жаргоне? А на чём? На доступных юзверу терминах типа:
"компутарщики", "вон та штука", "всё такое цветастое". 5 баллов афтору!
Представьте себе манагера-диспетчера, который не зная терминов рулит посадкой аэробусов... Полярный лис вам светит!
Вам и вашему проекту!

"Разработчики всегда называют неверные сроки."
Правильные сроки никто не говорит. Указывают ориентировочные сроки. И чем более типовая и простая задача, тем точнее сроки.
Хотя, со сложными проектами, то ж можно сроки указать достаточно точные. Главное чтобы гуманитарии не рулили проектом.

"Разработчику свойственен врожденный оптимизм."
Пиздешь. С годами приходит похуизм и хорошо информированный реализм. Оптимисты сваливают в продавцов или грузчиков.

"Нельзя делать "по-хорошему"."
С учётом сроков задачи "ещё вчера" и хаотичностью "бросайте всё"... Но кто я такой чтобы спорить с гуманитарием?

"Правило 7. Приминание травы может отнять любое количество времени.
Программист всегда стремится удовлетворить свою потребность в вооруженности - максимально обустроить рабочее место, то есть создать инструментарий, установить самое последнее программное обеспечение, самую современную технику. Если дать ему волю, он потратит на это 100% рабочего времени, причем сумеет доказать начальству необходимость такой работы.
Верный признак такого перманентного обустройства - полуразобранные компьютеры на рабочих местах и необычные, нестандартные программы на этих компьютерах."
Типичный опус манагера-гуманитария, ни на грамм не понимающего работы программистов. Работа программистов для них - это магия приминания травы.

"Разработчик не интересуется бизнесом, он - типичный автор."
Конечно не разбирается. Чё там разбираться? Первый год может и есть новизна, а затем банальные затупы гуманитаев.
С учётом распила манагеров, к которому разработчик не допущен, остаётся только "тупо выполнять выданные задачи". Без энтузиазизма и оптимизма
на повышение зарплаты.

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