7212
правок
Изменения
м
Нет описания правки
Чтобы мыслить проектно, необходимо понимать не только свою работу, но концепцию всего проекта и работу других участников — только тогда возможно понимание и синергия совместного мышления. Я расскажу о том, почему нужно мыслить проектно и как этого достичь.
Доклад вызвал большое обсуждение в кулуарах и на FB, часть вынесена сюда [[#Из обсуждений]], а остальное - по ссылкам.
= Видео =
{{vimeoembed|298790421|800|450}}
= Из обсуждения обсуждений =
== В посте Димы Безуглого == В [https://www.facebook.com/photo.php?fbid=10215049070717988&set=a.1914289494739&type=3 посте Димы Безуглого] продолжается было большое обсуждение, часть вынесена сюда, остальное - по ссылке, читайте...
[[Файл:SECR-2018-ph1.jpg|300px|right|thumb|[https://www.facebook.com/photo.php?fbid=10215049070717988&set=a.1914289494739&type=3 Фото Димы Безуглого]]]
: Дмитрий Безуглый Максим Цепков Если внимательно слушать "гуру" , то можно понять что agile не только не технология, но даже и не методология ...
Про порог входа верно , но в целом вход в agile начинается со 2 у уровня CMMI "не тушкой, так чучелком" и по сути представляет улучшение его же. Но на полный 3-й уровень ни в одной своей ипостаси в не поднимается, хотя есть элементы и 4-ого и 5-ого. Но снижение порога имеет свою цену ..
== Пост Юрия Пахомова ==
'''Юрий Пахомов''' посмотрел доклад в записи и написал [https://www.facebook.com/permalink.php?story_fbid=2215738815153475&id=100001521332536 '''большой пост'''] по мотивам. Тоже выношу сюда, потому что много интересных мыслей.
SECR-2018: КАК Я ПРИДУМАЛ AGILE
Смотрю доклад Максима Цепкова об истории проектирования и возникновении Agile в контексте этой истории. Ну прям родное до боли 🙂
# Выяснилось, что в разработке невозможно снять неопределенность на этапе проектирования. Соответственно, разработку следует переместить из блока "производство", куда она была помещена ошибочно, в блок "НИОКР". <br/>Это - о фактической истории развития идей в проектировании. Интересно, что года четыре назад я пришел к похожим соображениям чисто умозрительно, просто исходя из своих личных ценностей и хотелок. Опираясь на разработки Н.А.Бернштейна в исследованиях движения (кольцо обратных связей), я показывал, что в сложной, непрозрачной, а тем более быстро меняющейся среде дискретное (на какой-то отрезок времени вперед) планирование вообще неэффективно: требуется перманентное перепланирование в режиме реального времени.
# Выяснилось также, что наиболее эффективный способ снятия неопределенности - это использование коллективного разума, что входит в острое противоречие с традиционными пирамидами управления: одна голова - десять тысяч рук. <br/>Аналогично, и к этой идее я пришел какими-то своими путями. В сложной среде выигрывать будут те, кто задействует весь интеллектуальный ресурс персонала компании. Одна из критических формул, которыми я тогда пользовался, была следующей. Многие создатели бизнесов, которые идеологически всегда решительно выступали за демократию и против принятой в СССР командно-административной системы, фактически, лицемерили. Не устраивала не сама командно-административная система, а их персональное место в ней: почему-то не на самой верхушке. Поэтому, получив определенные возможности в микросоциальном строительстве, многие стали создавать те же командно-административные системы, только с трубой пониже и дымом пожиже. Возможно, иногда это происходило даже против воли создателей - как необходимость выживания в условиях быстрого роста численности компании и неведения относительно практик Agile. Мне доводилось слышать откровения многих бизнесменов. Но ни разу я не сталкивался со случаем, когда бы эта ситуация была отрефлектирована.
# Думать за пользователя. <br/> Эта идея не была мне близка: значительную часть жизни я позиционировал себя как наемного работника и не пытался влезть в шкуру предпринимателя на открытом рынке. Однако, и тогда у меня вызывали сильный внутренний протест попытки подрядчика принимать решения за заказчика не в технических, а в сущностных и даже в ценностных вопросах.
# Исследовать проблемную ситуацию, формулируя и переформулируя исходную задачу. "Не автоматизировать исходный процесс, а удовлетворить потребности стейкхолдеров!" <br/>Практического опыта работы с заказчиками в этом ключе почти не было, но на уровне размышлений и проведения тренингов по решению технических задач - тема знакома еще с советских времен. Пожалуй, лучше всего она разработана в традиции ТРИЗ, особенно в некоторых последних тризовских веяниях, связанных с рекомендациями думать не только за конечного пользователя, но и за каждого их стейкхолдеров.
# От создания функционирующего продукта (проектная организация) - к непрерывному развитию продукта (продуктовая организация).
# Управление стейкходлерами. Неважно, в каких сферах возникли хрестоматийные кейсы, когда маленький и хитрый выигрывает у больших, играя на конфликтах между ними. Если говорить о "позитивном" развороте темы, то здесь на теоретическом уровне многое сделано в СМД-методологии в связи с шагом проблематизация-объективация. Не могу, однако, засвидетельствовать, что наблюдал реализацию этой теоретической идеи на практике. При этом интуитивно кажется, что тризовские техники работы с противоречиями здесь не пройдут.
# От ИТ-проекта - к гуманитарному проекту. Однажды я пытался довести мысль руководителя компании-вендора до логического предела, на котором ИТ-компания трансформируется в HR-компанию. Ему такой ход очень не понравился. И вот теперь Максим делает тот же ход: от ИТ-бизнесу к бизнесу по командообразованию стейкхолдеров. Интересно, в какое мере Custis реализует это на практике.
= Презентация =
