Комментарии 55
Странно конечно, что во всей выкладке не ясно какая часть работ была выполнена по прошествии 11 недель из 16. Только это решает можно идти в отпуск или нет.
С точки зрения EV — выполнен ровно тот объем, который равен объему по затраченному времени. Вопрос действительно важный)
Топовые способы разработки и управления командой разработчиков можно пересчитать по пальцам двух рук) Но конечно нужно не забывать, что в жизни может случается все что угодно, и молния может ударить в одно место =) нужно быть готовым во все оружии.
В этом случае я бы Ивану посоветовал задуматься о мотивации, не в классическом её бехевиаристском понимании, а в новых трендах — Мотивации 2.0 и коррекции окружения команды под идеологию "человеческого фактора" (есть такой замечательный труд Т.Листера и Т.ДеМарко)
Описана классическая схема управления проектом. Сразу возникает вопрос — а в чём отлчие от других?
Проблемы здесь точно такие же.
Во первых представляется крайне сомнительным что можно заранее расписать все задачи и определить из трудоёмкость. Это можно сделать только для очень простых проектов.
Во вторых также крайне сомнительна возможность создать иерархию задач. Обычно иерархия недостаточно точно описывает систему.
Ну и про Ивана — отпуск это святое, конечно он может уйти.
Попробуйте привести еще пару методик позволяющую строить такой прогноз =) и вы ответите на свой вопрос.
При должном уровне компетенции, проектирования решений, наличии опыта, построить такие модели по проектам IT индустрии не представляет сложностей.
Иерархия описывает не систему, а структуру работ — классическое понимание WBS или ИСР. Подробней можно прочитать в стандартах по управлению проектов от ведущих проектных институтов (как пример IPMA, PMI).
У вас пример из области программирования. Вот простой пример который не укладывается в иерархию. Вводим допущение, что в компании, где работает Иван, Вячеслав и другие разработчики, в течении долгого времени разрабатывается какая то библиотека. На основе этой библиотеки делаются разные проекты для разных заказчиков. Библиотека развивается, каждый новый проект для заказчика вносит что то новое. Или улучшает старое. Команда программистов бережно относиться к этой библиотеке, её развивает, холит и лелеет.
В результате описать ВСЕ работы компании в виде иерархии не получается. В рамках проектного управления будет отдельный проект для библиотеки, отдельные проекты для каждого из заказчиков. Но это уже искусственное ограничение. Эти работы могут быть описаны в рамках сетевой модели, и это будет органично.
Развитие продукта подразумевает выполнение нескольких проектов / проведение операционной деятельности. То что вы написали — развитие продукта, здесь нужна другая компетенция, конечно компетенция проектного управленца нужна, но её не достаточно, для этого дополнительно необходимо еще навыки стратегического менеджмента и операционного управления.
Я не сказал, что проектный подход не нужен, он необходим, но не достаточен.
Этому слову в разработке IT в России, как минимум 15 лет, в мире же в IT проекты появились начиная с 50х годов. Сам руковожу проектами разработки уже более 10 лет, и поверьте именно такой подход наиболее эффективен для создания продуктов, программ и игр.
А вот методик разработки много, и в каждом проекте есть свои наиболее эффективные.
Так что проектный подход это просто модный термин. За ним стоит только одно — это система распределения денег. Собственно именно это является основным в PMBoK. Остальное — дымовая завеса. Где-то в какой то компании это сработало. Видимо в результате случайностей кто-то из авторитетных руководителей придумал схему и модный термин. У них получилось. А дальше просто образовался карго-культ. Вот давайте сделаем такие же названия и оно само образуется. И ещё метрики введём. И чем более непонятны метрики тем лучше.
Так что позвольте вам не поверить про наиболее эффективный подход. Проектный подход как то работает, он создаёт иллюзию контроля. Но считать его панацеей и серебрянной пулей как то странно.
Предлагаю ознакомиться с классикой — "Мифический человеко-месяц, или Как создаются программные системы", Брукса выпуском 1975 года — об управлении проектами в разработке IT. Кстати о распределении денег там нет)
К слову о серебряной пуле, на это тоже есть интересный труд — «Как успешно руководить проектами. Серебряная пуля» Ф. О'Коннэл об этом говорил в 2002, и тоже про IT и разработку.
Если же вы говорите о PMBoK — попробуйте хоть что-то сделать на основе подходов зафиксированных в нем, разгоните непонятную дымовую завесу и вы увидете за ней Небоскреб.
Он что-то полезное делает?
Или только руководит?
Но самое главное — Иван первый кто берет на себя ответственность за успех проекта, в том числе, первый кто попадет под санкции.
И давайте уточним его квалификацию, что он вообще может делать.
— управление стоимостью проекта
— управление сроками проекта
— управление рисками проекта
— управление заинтересованными сторонами проекта
— управление поставками/закупками проекта
— управление содержанием проекта
— управление интеграцией проекта
— управление качеством проекта
— управление человеческими ресурсами проекта
— управление коммуникациями проекта
Вот давайте ещё раз рассмотрим вашу задачу:
В начале выполнения проекта аналитик Петр с точностью до секунды уложился в сроки подготовки материалов для своих коллег программистов, постановки были выверены и согласованы с клиентом, спецификации для разработки были отточены до «11 знаков после запятой».
Т.е. всё самое важное — сделал Пётр. По контексту видно что он не советовался с программистами и руководителем.
Что делал Иван в это время? Подходил и спрашивал «как дела ?»
Если же говорить, что делает Петр — он как минимум обеспечивает проектную деятельность (управление интеграцией проекта), участвует в согласовании постановок с клиентом (контроль содержания проекта), планирует будущие активности, генерирует отчетность перед заказчиком и руководством, контролит ход выполнения проекта (в том числе и с помощью EVM), обеспечивает должное исполнение контрактных обязательств и выполнение требований контракта (в том числе и формальных вех)… и многое-многое другое, если интересно — напишем и про это, что он должен делать… но это уже совсем другая тема.
А еще, если ему руководство доверяет, он может делать пре-сейлы, сейлы и ап-сейлы по другим проектам =)
То что вы написали про руководителя проекта это конечно классическое определение. Но оно ещё как то может быть оправдано для больших проектов. Но не для проекта в котором задействовано четыре человека.
Я не зря спросил про квалификацию Ивана. Давайте всё таки выясним что он может делать. Основные вопросы:
1. Он является специалистом в предметной области?
2. Он является программистом?
3. Он работал вместе с Петром над спецификациями? Т.е. он вообще знает что в проекте твориться?
Пока из ваших ответов я понял что он занимается общим руководством, для меня это означает что он является совершенно бесполезным человеком в этом проекте. Из этого вытекает следствие, что самое лучшее что он может сделать это уехать в отпуск. Это нужно что бы не мешаться под ногами у программистов в самый ответственный момент.
Я отвечу коротко и ёмко, если руководитель проекта не понимает в своём проекте и не знает его сути, не приносит ему пользу — это не руководитель проекта.
Я описал не классического руководителя, а тех людей которые проходят успешно у меня собеседование. Это минимальный набор требований к специалисту для работы на этой позиции.
Аналитик, программист, инженер — сами по себе могут быть отличными специалистами. И на маленьком проекте (коротком, с микрокомандой) вполне могут сработать самостоятельно. Хотя даже при этом у них могут возникнуть проблемы с работой с заинтересованными сторонами и с бизнесовой ценностью, так как они увлечены технической частью, а не «всей вот этой фигнёй».
Руководитель проекта видит проект полностью, а не отдельными кусками, которые касаются предметной области каждого технического специалиста. И руководитель обеспечивает интеграцию всего этого зоопарка вместе. Разруливает конфликты, минимизирует ущерб от конфликта интересов и т.д. и т.п.
Полностью видеть проект может только тот кто обладает квалификацией, разруливать конфликты — человек с авторитетом, который ещё надо заработать. Собрать зоопарк вместе — это вообще высшая квалификация, руководителям она обычно не доступна. Хотя бы потому что когда человек начинает руководить и перестаёт работать руками то квалификация теряется.
А мы не говорим про других руководителей проектов, именно по этому толковых руководителей проектов мало. А если заниматься проектом всесторонне, квалификацию не потеряешь, а только прокачаешь.
Теория штука такая, пока не будешь применять на практике, она работать не будет. Попробуйте, увидете.
Это кстати то что PMBoK сразу отвергает, утверждая что это неэффективная структура но не приводя убедительных доказательств.
PMBoK описывает разные варианты организационной структуры и как от этого зависит реализация проектов. Описанный вами вариант зачастую является наиболее неблагоприятным для проектной деятельности из-за больших информационных и управленческих издержек.
Признаю, я достаточно поверхностно знаю PMBoK, но я не вижу причин туда углубляться. Только потому что это модно?
Вопрос сложный, вполне может быть что я не прав. Но именно для этого и ведётся дискуссия. Мне по крайней мере интересно. Если вам тоже интересно — то можно продолжить. Пока что я не увидел хороших аргументов в защиту проектного подхода. Как только доходит до конкретных вопросов сразу идёт уход в сторону от ответа.
Давайте ещё раз рассмотрим гипотетическую ситуацию. Компания в течении долгого времени разрабатывает библиотеку. На основе этой библиотеки выполняются различные проекты для совершенно разных заказчиков. Где в этой структуре место для проектного подхода? Где место руководителя, где место программистов и главное — как и за что платить деньги программистам.
Это сразу ограничивает кругозор рамками данного проекта.С одной стороны это не плохо, потому что одна из задач менеджера проекта — предотвратить расползание проекта (scope creep).
С другой стороны есть такая штука как управление знаниями, библиотека извлеченных уроков и т.д. — чтобы не держать проекты в информационной изоляции.
А так же есть программное и портфельное управление, обеспечивающее взаимодействие проектов между собой.
Это задаёт методику поведения — после нас хоть потоп.Проект направлен на создание УНИКАЛЬНОГО продукта или услуги. Поддержка проекта после сдачи — задача важная, но относится к операционной деятельности. Частично относится к проекту, а в остальном — к портфельному уровню управления.
Т.е. сейчас сдадим и всё. Следующий проект с чистого листа.Если проект нормально документировался, были оформлены извлеченные уроки и т.д. — это с успехом может быть взято в следующий проект.
Только потому что это модно?Всё вы пытаетесь выставить PMBoK в уничижительном свете. А даже если и так, то он модный потому что… хороший?
аргументов в защиту проектного подходаДавайте определимся с терминами. Если вы против проектного подхода, то есть некий не проектный? Это какой? Не проектный это по идее операционный подход. Попробуйте при операционном подходе сделать что-то уникальное в срок и бюджет.
Проектный подход — ответ на высокую неопределенность и изменения. Я не буду вспоминать про Гантта, но такие инструменты как Метод критического пути и PERT появились в 40-х — 50-х годах ещё задолго до PMBoK и затем успешно в него вошли.
Плюсы проектного подхода — в том числе в его универсальности. ГОСТ 34 расскажет вам как создать, испытать, задокументировать автоматизированную систему, но ничего не скажет про сроки и бюджет. И к созданию автомобиля его не особо применишь. А проектный подход создает управленческий каркас, внутрь которого помещается нужное техническое наполнение.
Давайте ещё раз рассмотрим гипотетическую ситуацию. Компания в течении долгого времени разрабатывает библиотеку. На основе этой библиотеки выполняются различные проекты для совершенно разных заказчиков. Где в этой структуре место для проектного подхода? Где место руководителя, где место программистов и главное — как и за что платить деньги программистам.Проекты выполняются, но проектному подходу места нет? Это как? То, что вы описываете, по идее вотчина системной интеграции — адаптация «библиотеки» к ИС организации или к бизнес-процессам организации. Не понятно что мешает платить программистам по часам и возможно некоторый бонус за успешное завершение в срок.
Проект направлен на создание УНИКАЛЬНОГО продукта или услуги. Поддержка проекта после сдачи — задача важная, но относится к операционной деятельности. Частично относится к проекту, а в остальном — к портфельному уровню управления.
Что такое уникальный? Если в проекте задействовано 10% наработок от предыдущих это уникальный проект? А если 90%? А можно сказать что операционной деятельностью компании является разработка новых проектов?
В примере компании действительно выполняются проекты но нет места проектному подходу. К обсуждению нового проекта и выработке плана реализации привлекаются наиболее квалифицированные разработчики. Они принимают решения о модификации исходной библиотеки (если необходимо). Далее оперативное руководство выполняют руководители подразделений.
Платить программистам по часам это ПРИНЦИПИАЛЬНО не правильно. В долгосрочной перспективе это приведёт к тому, что программисты будут вырабатывать человеко часы а не программы. И вместо оптимальных решений будут искать решения которые позволят им заполнить человеко часы на проекте. Про единую библиотеку можно забыть. Так что в долгосрочной перспективе (десятки лет) проектный подход вреден.
Что такое уникальный? Если в проекте задействовано 10% наработок от предыдущих это уникальный проект? А если 90%? А можно сказать что операционной деятельностью компании является разработка новых проектов?
Давайте посмотрим что об этом говорят умные книжки

Вообще, если у вас такой негативный опыт с проектным управлением, то может, что-то в консерватории подправить? Ничего удивительного в таком положении вещей нет. Вот опрос ~120 руководителей проектов на одной из недавних конференций:

А про ЗП программистов я просто не понял ваш вопрос. Тут я не великий эксперт в системе оплаты труда именно программистов (как формируется премиальная часть, какие KPI и т.д.). У меня программных проектов очень мало, в основном интеграционные и поставочные.
А вы упорный :)
Рад стараться :-)
Вообще, если у вас такой негативный опыт с проектным управлением, то может, что-то в консерватории подправить?
Может быть что то не так именно с проектным управлением?
Второй график можно интерпретировать так что половине компаний это оказалось совершенно не нужным. Но они не смогли отбиться от внедрения.
Самое интересное в нашей дискуссии это найти границы применения этого самого проектного подхода. Он не может охватить всё и везде быть эффективным. Так просто не бывает. Поэтому я считаю ложными утверждения о том что проектный подход (и в частности PMBoK) это наше всё и по другому нельзя работать.
Одно ограничение мы уже выяснили — это разделение операционной и проектной деятельности. Но оно тоже достаточно условно. В рамках операционной деятельности тоже могут выполняться проекты и достаточно сложные.
График показывает что предпочтительная область проектного подхода — это разработка с нуля. Но это достаточно редко. По сути — это создание новой компании для новой деятельности. В реальности все разработки идут на основе предыдущего опыта. У нас норма это 80-90% задела. Если меньше — скорее всего не заработает.
А про ЗП программистов я просто не понял ваш вопрос.
Тут тоже всё просто — если вы собираетесь платить за отработанное время, то люди будут вырабатывать время. Если за результат — будут вырабатывать результат. Если результат будет представлен в виде KPI — будут вырабатывать KPI.
Причём здесь есть обратная зависимость. Идеальное состояние это когда люди не работают а результат есть. Классический пример — это ремонтная бригада на заводе Форда. Они получали деньги когда сидели в комнате отдыха. Также и с программистами. Надо что бы они минимальными усилиями получи максимальный результат. Оплата за отработанные часы в проекте это самый худший вариант из всех.
по другому нельзя работать.Да почему же нельзя? Конечно можно. На PMBoK свет клином не сошелся, есть ещё семейство Agile подходов. Хотя в последней редакции PMBoK рассказали и об Agile.
Так вот, на «считаю ложными утверждения о том что проектный подход (и в частности PMBoK) это наше всё и по другому нельзя работать» вспомнился анекдот: «жили они плохо, но не долго».
Весь мир живет в проектном управлении и оно преобразуется под нужды трудящихся, основная цель сделать то, что еще никто до тебя не делал в рамках определенных ограничений.
Вопрос оплаты — это вопрос вторичный. Приведенный вами пример — пример не из проектной деятельности. Подходы Форда верные, но они в операционке — не забывайте.
Есть замечательные специалист которые на своем опыте могут вам рассказать что такое проектный подход и как его внедрять, крайне советую. Но как минимум — ознакомьтесь с книгами, которые я порекомендовал. А потом, предлагаю обсудить =)
Весь мир живет в проектном управлении
Не надо говорить за весь мир, это не так.
Есть замечательные специалист которые на своем опыте могут вам рассказать что такое проектный подход и как его внедрять
Конечно есть специалисты, расскажут, покажут и возьмут деньги. Собственно это их работа, они как раз прекрасно зарабатывают деньги на теме проектного подхода. И это не единственный пример. Можно ещё вспомнить МММ. На этом тоже многие заработали.
А потом, предлагаю обсудить =)
Тоже хорошая мысль. Обсудим.
Но я подвергаю сомнению самые основы — откуда взялись эти цифры. Например с трудоёмкостями. Например можно посчитать поставленные задачи и выполненные. Получаем процент. Вот только чего? Задачи равнозначные? Или есть какая-то сложная задача и много мелких.
Но перед самой сдачей проекта средняя температура не имеет никакого смысла. Имеет значение только список не сделанных задач. Причём каждая задача требует индивидуальной оценки. А здесь мы опять возвращаемся к вопросу о квалификации руководителя проекта.
Это средняя температура по больнице
Все верно. Оценка по EVM нужна чтобы РП ( а на самом деле куратор проекта, который выделяет бюджет) понял — проект сейчас ОК или не ОК. Детали и причины конечно же одной двумя цифрами не раскрываются. Но если у вас индекс 0.6, то объяснить, что все идет нормально вам будет трудновато )
Но я подвергаю сомнению самые основы — откуда взялись эти цифры. Например с трудоёмкостями. Например можно посчитать поставленные задачи и выполненные. Получаем процент. Вот только чего? Задачи равнозначные?
В примере, который описал автор, смоделирована идеальная ситуация: мы и оценили все задачи точно и прогресс по задачам идет пропорционально выработке. Согласен с вами, что в жизни такое происходит редко. Мне кажется в кейсе это сделано специально, чтобы не усложнять. Так же для упрощения нет декомпозиции работ и мы рассматриваем все работы по проекту, как единое целое. По сути совместное копание большой ямы в течении 4х месяцев.
На самом деле EVM позволяет учитывать и декомпозицию работ. Только все работы нужно оценивать в одних у.е. = деньгах, часах, попугаях, кому как нравится.
Управляем стоимостью проекта с Earned Value Management