Pull to refresh

Comments 39

Как бы тимлида вышеописанное не очень касается. Или вы были и тимлидом и PO в одном лице?
Хотя, возможно, у нас различное понимание термина team leader.
Когда я был тим лидом, меня очень напрягали оценки задач, которые приходили сверху. Сейчас я менеджер проектов, и в мои обязанности входит построение и поддержка правильного Процесса Разработки.

Статья действительно больше для менеджеров проектов, но, надеюсь, вопросы, которые обсуждаются, волнуют и тим лидов.

Кроме того, каждый тим лид со временем становится менеджером проектов как правило. :)
P.S. Термин тим лид я использовал для обозначения члена команды, который выполняет задачи «локального» менеджера (для 2-5 разрботчиков) и одновременно выполняет задачи по кодингу.
Предложение «Все поменялось в 2004, когда меня назначили тим лидом.» способствует восприятию изложенного от лица тимлида, а не PM :) Спасибо за разъяснение.
супер!!!

интересны ваши результаты в следующих проектах
Ну вот CMMI аттестации не по заслугам досталось. На самом деле CMMI никому не мешает использовать тот же Scrum. CMMI не определяет конкретной методологии разработки. Я сам работал фирме, аттестованной по 3-ему уровню CMMI, и при этом все использовали Scrum и XP.
Спасибо за вопрос.

Действительно, Скрам процесс может получить CMMI 3. Но это потолок. Уровни 4 и 5 получить нельзя, поскольку полный набор требований CMMI разработан из предположения детерминантного процесса.

Кстати, вот в этой книге (по секрету — я нашел ее CHM в сети) — Agile Project Management with Scrum by Ken Schwaber  ISBN:073561993x Microsoft Press © 2004. — применению Скрам для CMMI посвящен небольшой раздел.
ценно, но всеравно как вы вкладываетесь в общий бюджет, если допустим заказчик _сильно_ хочет эту перделку и она сильно задежит всю команду, мне непонятно %)
Я не вижу тут противоречия на самом деле. Заказчик решил вкинуть мегафичу? На здоровье! Но при этом он, конечно, должен знать правила игры. Эта мегафича подвинет другие — с меньшим приоритетом. Заказчик может выбрать один из вариантов — либо бюджет увеличивается на вес оценки этой фичи — либо другим фичам не повезло в этот раз — они выходят за скоуп.
> Тогда я начал задумываться о причинах такой ситуации, начал читать посты и книги по менеджменту. Как программист, находящийся под впечатлением революционных архитектурных решений — таких, как MVC и паттерны Фоулера, я полагал, что есть *техническое* решение наших проблем с менеджментом — нужно его только отыскать и применить.

> The original publication date of the book was October 21, 1994 with a 1995 copyright, and as of April 2007, the book was in its 36th printing. The book was first made available to the public at OOPSLA meeting held in Portland, Oregon in October 1994. It has been highly influential to the field of software engineering and is reg

Вашей «революции в архитектуре» уже 15 лет.
Я так понимаю, что у вас претензии к фразе: «революционных архитектурных решений — таких, как MVC и паттерны Фоулера».

Я не собираюсь спорить на тему «cтарые или новые» MVC и слоистый паттерн. Статья в общем, о другом. Вы можете в этом месте вставить любую *новую архитектурную революцию* на ваш вкус и читать статью дальше.

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

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

В целом имхо это просто разделение уровней — есть управленческий, где ПМ и его руководство с заказчиком, и выполняющий, где ПМ же, исполнители и представитель заказчика же. Они вполне могут иметь разные процессы, наиболее удобные участникам. Главное что бы работало.
>>В описанной ситуации с изменениями фич нет ничего с чем не справился CMM. Просто нужно соответствующее управление изменениями в скопе проекта. При этом правда нужно ПМ-у активно поработать.

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

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

>>Отодвигать решение проблемы с классической тройкой время-деньги-обьем на этап завершения нехорошо

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

>> заказчик может думать что начальные деньги и сроки классный ПМ сопряг с новыми фичами, а контора верить в то что дополнительный обьем и увеличенные сроки будут финансово поддержаны спонсором проекта

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

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

Я почти с вами согласен :)
Я бы только слово «могут» заменил на «должны». Это и есть главный *месседж*, который я хотел отправить.

Спасибо за ваш комментарий.

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

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

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

Именно, я набил эту шишку, когда увлекся Скрам и убедил своего топ менеджера, что мы обойдемся вообще без артефактов детерминантного процесса и все проведем по модели *постоянное общение + частые оценки + 2-недельные итерации с презентациями*. Тот проект мы завалили…

Нельзя игнорировать *легаси* или исторически сложившийся массив связей между людьми, возглавляющими фирму и их клиентурой.

Поэтому я предлагаю «панцирь» процесса строить и поддерживать в детерминантном подходе, а внутренности — в эмпирическом.

>>Спускаясь с теоретизирования, люди — разные. Одному может быть до фени те пять копеек что будут доплачены за доп.фичу по сравнению с ее выгодой, а другому для этого нужно согласовать изменение бюджета по 20-ти инстанциям и пофиг что от нее будет лучше и денег больше. Это нельзя не учитывать.

Я не претендую на универсальное решение проблемы. У нас — а это небольшая команда из 35 разработчиков — стратегия сработала (по крайней мере один раз). Но вполне возможно, что она не годится для компаний-флагманов рынка с командами в 200 или 400 человек.
«процессы, которые очень тяжело поддаются прогнозу и планированию — научные исследования, космические программы и, наконец, движение автомобиля такси»
А что не так с этими процессами (особенно первые два), они может даже более строго детерминированы, чем Вы можете себе представить, просто вы не знаете, как это работает. С такси особая проблема — и тоже вполне предсказуема в современном мире.
Сложно предсказать когда и главное чем закончатся научные исследования. Можно дать лишь примерную оценку ожидаемому результату и ожидаемым временным затратам.
Нет. Научные исследования это строго детерминированный процесс. Сужу по своему 3х летнему опыту и опыту друзей, которые работают в больших лабораториях (Ферми Лаб, Церн). План научного исследования это строго определенная и ограниченная по времени задача.
Прикладной пример — задача разработать методику распознавания испорченных продуктов в холодильнике. Составляется довольно детальный план измерений, исследований, испытаний, и приступают к делу — это в инженерной культуре. Никто не сидит и не ждет, пока к нему в голову придет гениальная мысль. Ученые так не работают.
Т.е. они приводят к гарантированному (с какой вероятностью?) результату?

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

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

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

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

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

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

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

Так где тут детерминантность?
если у вас такое случается, то это, наверное, будет последнее исследование которым вы руководите.
Но оно будет у всех ученых, за исключением того одного который опроверг правильность текущего подхода. Если так, то еще тысячи лет назад все ученые провели бы по своему последнему исследованию и мы сейчас даже слова такого не знали.
в 99.9% случаев такого не бывает. Давайте ещё учитывать срыв планов, потому что лабораторию разломало землетрясением.
теперь надо сделать программный менеджер управляющий данным подходом
Схема интересная, но на мой взгляд имеет недостатки с точки зрения клиента:

1. В начале проекта заказчику будет сложно объяснить схему. Многие клиенты не хотят даже вникать почему у подрядчика А будет качественнее подрядчика Б, не говоря уже о процессе, в котором нужно делать много телодвижений.
2. У больших компаний всегда есть потребность, под которую выделяется бюджет и каждый новый проект проходит согласования на разных уровнях, поэтому поменять что-то в процессе будет очень сложно. Кроме того, ответственный менеджер не станет рисковать самостоятельно менять функционал.
Согласен, эти проблемы существуют и, наверное, являются общими для всех компаний, которые вводят Agile процессы в легаси структуру. Тут вопрос в выходе на новые горизонты рынка — нужно сохранить клиентов, которые привыкли к детерминантному процессу, и привлечь новых, кто ищет интерактив и готов идти по эмпирическому процессу.

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

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

Это не простой вопрос… Нужно подумать…

Спасибо за комментарий.
Мы сейчас тоже думаем над системой проектного менеджмента (у нас создание сайтов, подобные услуги). Вернее стараемся улучшать эту систему. Сейчас работаем над вводом разных процедур, которые будут поддерживать смешанную систему, эффект положительный.
Я извиняюсь, конечно, но фраза «К эмпирическим процессам, безусловно, относится и разработка ПО.» выглядит больше как оправдание.
Разработка ПО — нормальный, предсказуемый процесс даже при при полностью неадекватном менеджменте верхнего уровня. Предсказуемость достигается с одной стороны, за счет разбиения задач на минимальные, поддающиеся оценке, составляющие, с другой стороны — за счет стройной архитектуры.
К сожалению не все так просто… В большинстве случаев заказчик на старте проекта имеет только набор идей того, что он хочет получить в результате проекта. Нету магической книги, из которой вы могли бы взять задачи, «разбить их, и имплементировать в стройной архитектуре». Описанная вами картина больше напоминает работу программиста над своим личным небольшим проектом.
Зря Вы так категорично. Описанная мною картина подошла как для разработки решений в международной компании с высоким уровнем бюрократии, так и в небольших организациях с постоянной текучкой всего чего только можно.
Sign up to leave a comment.

Articles