Текущая версия на 18:21, 7 декабря 2023

Доклад на конференции SECR-2018 12.10.2018 в Москве
Доклад на сайте конференции
Доклад в библиотеке Стаса Фомина

Аннотация

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

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

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

Предыдущая версия Развитие управления проектами и критериев качества в ИТ была на AgileDays-2015.

Доклад вызвал большое обсуждение в кулуарах и на FB, часть вынесена сюда #Из обсуждений, а остальное - по ссылкам.

Видео

Видео на vimeo

Из обсуждений

В посте Димы Безуглого

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

Фото Димы Безуглого

Дмитрий Безуглый О проектном мышлении, о том что у них не получалось разрабатывать по RUP, не получалось по agile ..и что нужно чтобы получилось ))

Дмитрий Волошин водопад!

Дмитрий Безуглый Дмитрий Волошин Ага )

Дмитрий Волошин и еспд

Рина Ужевко водопадный аджайл 😊

Максим Цепков Водопада в докладе не было вообще. Так же как ЕСПД. Слайды - опубликованы.

Taya Saburova Гибридные методологии?

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

Максим Цепков Нет. Это в вечном неизменном мире мы носим вечные проблемы. А мир - развивается, ставит новые задачи, по мере которого как старые мы учимся решать. И решение этих задач вызывает развитие культуры.

Максим Цепков Дима, я не понял интерпретацию доклада. У кого "у них не получалось"? Доклад был про отраслевой опыт и изменение культур ведения программных проектов, я об этом рассказываю с 2015 года, и, кстати, визуальный ряд доклада появился тогда. При этом тема - развивается, это не повторение старых докладов. А если говорить конкретно об опыте моих проектов и проектов нашей компании, то мы их успешно делаем и наши клиенты это оценивают. При этом RUP я с самого начала оценивал как бессмысленные процедуры, и не пытался применить в силу явной работоспособности, а вот Scrum в свое время дал определенный импульс развития, а потом - сильно изменился внутри. И сейчас компания продолжает меняться. А в отрасли - как было 20-30% успешных докладов - так и есть. RUP и выросший из этого PMBOK не смог это повысить, повысив при этим стоимость, а Agile - дает примерно те же цифры, но дешевле и добавляет самонаведение на цель. А фокус доклада был не на этом, а на том, что в последнее время (с 2012) принципиально изменилась рамка проекта - хотя далеко не все люди это осознали.

Дмитрий Безуглый Максим Цепков Посмотри видео , ты так хотел продать Agile что многократно прозвучали обобщающие оценки. RUP не работает , Академический не работает и т.д. Потом ты постарался объединить но из песни слов не выкинешь

Максим Цепков Дима, я не продавал Agile. Вообще, Agile - стандарт дефакто в глобальной IT-отрасли давно, с 2007 года примерно. Академический подход не смог ответить на конкретные вызовы, проекты фейлились. Попытка классического менеджмента тоже провалилась, Мифический человеко-месяц об этом. Следующая итерация, RUP тоже не смог ответить на конкретные вызовы, и потому пришел Agile, который на них успешно ответил. И потом, естественно, появились новые вызовы, ответ на которые в agile-практиках не содержался, и как ответ на них - возникали новые практики и новая культура. Уже.

Это все история. И она произошла и ее надо понимать. Чтобы представлять, что прежде попытки применить старые подходы из учебников, написанных до попыток их применения, стоит посмотреть на результаты. Включая попытки применить Agile, который уже тоже старый подход со своей историей фейлов и успехов, и на ее историю тоже надо смотреть.

А еще - надо представлять законы диалектического развития (в варианте диалектического материализма, смотрите эти статьи). Agile явился отрицанием RUP и академической культуры, принес новое. То, что происходит сейчас и несет отрицание Agile, и ври этом, естественно, использует переосмысленные практики более ранних конструкций для синтеза нового. При этом часть представителей прошлой культуры, увидев это их близкое сердцу старое просто удовлетворенно говорят "наконец-то этот кошмар agile-культуры кончился и происходит возврат". Нет, возврата не происходит, это все - история и не понимание диалектики развития.

Дмитрий Безуглый Давай по правде проекты проваливались, проваливаются и будут проваливаться. Более того успешные проекты делаются и делались и большая часть успешных продуктов появилась до Agile и продолжает появляются без Agile )) Agile is not silver bullet . Особенно agile for teams. До тех пор пока нет приемлемой статистики по успешности проектов все заявления о стандарте же факто не являются доказательством лучшей эффективности или целесообразности. Диалектику я не забываю ))

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

Дмитрий Безуглый Максим Цепков Если внимательно слушать "гуру" , то можно понять что agile не только не технология, но даже и не методология ...

Про порог входа верно , но в целом вход в agile начинается со 2 у уровня CMMI "не тушкой, так чучелком" и по сути представляет улучшение его же. Но на полный 3-й уровень ни в одной своей ипостаси в не поднимается, хотя есть элементы и 4-ого и 5-ого. Но снижение порога имеет свою цену ..

Пост Юрия Пахомова

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

SECR-2018: КАК Я ПРИДУМАЛ AGILE Смотрю доклад Максима Цепкова об истории проектирования и возникновении Agile в контексте этой истории. Ну прям родное до боли 🙂

1. Выяснилось, что в разработке невозможно снять неопределенность на этапе проектирования. Соответственно, разработку следует переместить из блока "производство", куда она была помещена ошибочно, в блок "НИОКР".
   Это - о фактической истории развития идей в проектировании. Интересно, что года четыре назад я пришел к похожим соображениям чисто умозрительно, просто исходя из своих личных ценностей и хотелок. Опираясь на разработки Н.А.Бернштейна в исследованиях движения (кольцо обратных связей), я показывал, что в сложной, непрозрачной, а тем более быстро меняющейся среде дискретное (на какой-то отрезок времени вперед) планирование вообще неэффективно: требуется перманентное перепланирование в режиме реального времени.
2. Выяснилось также, что наиболее эффективный способ снятия неопределенности - это использование коллективного разума, что входит в острое противоречие с традиционными пирамидами управления: одна голова - десять тысяч рук.
   Аналогично, и к этой идее я пришел какими-то своими путями. В сложной среде выигрывать будут те, кто задействует весь интеллектуальный ресурс персонала компании. Одна из критических формул, которыми я тогда пользовался, была следующей. Многие создатели бизнесов, которые идеологически всегда решительно выступали за демократию и против принятой в СССР командно-административной системы, фактически, лицемерили. Не устраивала не сама командно-административная система, а их персональное место в ней: почему-то не на самой верхушке. Поэтому, получив определенные возможности в микросоциальном строительстве, многие стали создавать те же командно-административные системы, только с трубой пониже и дымом пожиже. Возможно, иногда это происходило даже против воли создателей - как необходимость выживания в условиях быстрого роста численности компании и неведения относительно практик Agile. Мне доводилось слышать откровения многих бизнесменов. Но ни разу я не сталкивался со случаем, когда бы эта ситуация была отрефлектирована.
3. Думать за пользователя.
   Эта идея не была мне близка: значительную часть жизни я позиционировал себя как наемного работника и не пытался влезть в шкуру предпринимателя на открытом рынке. Однако, и тогда у меня вызывали сильный внутренний протест попытки подрядчика принимать решения за заказчика не в технических, а в сущностных и даже в ценностных вопросах.
4. Исследовать проблемную ситуацию, формулируя и переформулируя исходную задачу. "Не автоматизировать исходный процесс, а удовлетворить потребности стейкхолдеров!"
   Практического опыта работы с заказчиками в этом ключе почти не было, но на уровне размышлений и проведения тренингов по решению технических задач - тема знакома еще с советских времен. Пожалуй, лучше всего она разработана в традиции ТРИЗ, особенно в некоторых последних тризовских веяниях, связанных с рекомендациями думать не только за конечного пользователя, но и за каждого их стейкхолдеров.
5. От создания функционирующего продукта (проектная организация) - к непрерывному развитию продукта (продуктовая организация).
6. Управление стейкходлерами. Неважно, в каких сферах возникли хрестоматийные кейсы, когда маленький и хитрый выигрывает у больших, играя на конфликтах между ними. Если говорить о "позитивном" развороте темы, то здесь на теоретическом уровне многое сделано в СМД-методологии в связи с шагом проблематизация-объективация. Не могу, однако, засвидетельствовать, что наблюдал реализацию этой теоретической идеи на практике. При этом интуитивно кажется, что тризовские техники работы с противоречиями здесь не пройдут.
7. От ИТ-проекта - к гуманитарному проекту. Однажды я пытался довести мысль руководителя компании-вендора до логического предела, на котором ИТ-компания трансформируется в HR-компанию. Ему такой ход очень не понравился. И вот теперь Максим делает тот же ход: от ИТ-бизнесу к бизнесу по командообразованию стейкхолдеров. Интересно, в какое мере Custis реализует это на практике.

Презентация

Скачать весь pdf