-ѕоиск по дневнику

ѕоиск сообщений в product_manager

 -ѕодписка по e-mail

 

 -—татистика

—татистика LiveInternet.ru: показано количество хитов и посетителей
—оздан: 10.11.2010
«аписей: 602
 омментариев: 758
Ќаписано: 2090

¬ыбрана рубрика agile.


ƒругие рубрики в этом дневнике: ”крѕил(8), светлые новости(65), обзоры(34), менеджмент(46), маркетинг(23), личное(357), коллажи(35)
 омментарии (0)

Agile в маркетинге

ƒневник

ѕ€тница, 10 ƒекабр€ 2010 г. 10:09 + в цитатник

 Launch Clinic пишет о том, что принципы Agile можно примен€ть и в маркетинге. Ёто будет выгл€деть следующим образом: вместо составлени€ больших планов на неопределЄнное будущее нужно составл€ть маркетинговые планы на мес€ц, причЄм с прицелом на ценность дл€ бизнеса. ¬ конце мес€ца подводить итоги и составл€ть план на следующий мес€ц. “акже проводить ежедневные встречи stand-up (т.е. сто€) минут на 15. Ќа этих встречах определ€ютс€ текущие моменты, решаютс€ текущие вопросы. ≈сли возникает какой-то непредвиденный момент, который мен€ет мес€чный план, то команда маркетологов должна решить, какой пункт мес€чного плана должен быть заменЄн неожиданно возникшим.

ѕо-моему, интересный подход. «десь главное - не зат€гивать все эти встречи и заседани€. 

–убрики:  менеджмент/agile
маркетинг

ћетки:  
 омментарии (0)

Ќе любите документацию? ƒумайте вместо этого о "стойких св€з€х".

ƒневник

—уббота, 04 ƒекабр€ 2010 г. 22:30 + в цитатник

 —котт —ельхорст написал замечательный пост у “айнера Ѕлейна о документации. Ќе технической документации, а информации, которую вы записываете, чтобы процесс разработки заработал. ѕод работой € не имею в виду только де€тельность внутри команды разработчиков, но и остальной цепочки создани€ стоимости тоже.

–убрики:  менеджмент/agile

ћетки:  
 омментарии (0)

8 опасностей внедрени€ Agile

ƒневник

¬оскресенье, 28 Ќо€бр€ 2010 г. 19:41 + в цитатник
 (500x335, 53Kb)
 ак будто внедрение Agile не было достаточно страшно,  ит –ичардс из KRC на конференции APM в прошлом мес€це говорил о 8 опасност€х Agile. ¬от они:

ќна переворачивает всЄ вверх дном

"ћы на самом деле не хотим, чтобы технари захватили организацию", - говорит  ит. "Ётот подход вверх тормашками немного опасен". ќн отметил, что Agile - это не что-то, что должно органично вырасти из »“-отдела. ”бедитесь, что ваше развертывание Agile - это сознательное решение.

ќна выгл€дит простой

"≈сли бы это было просто, нам не пришлось бы обучатьс€ в PRINCE2", - сказал он. Ќа мой взгл€д, всЄ просто, когда вы знаете, как это работает, но Agile выгл€дит обманчиво простой со стороны. Ѕудьте осторожны с реализациуй, рекомендует  ит.

Ёто смешение масла с водой

Agile имеет особый подход к управлению, который не очень хорошо сочетаетс€ с некоторыми т€жЄлыми структурами корпоративного управлени€. Agile (по моему мнению) не против управлени€, но она гибка€. Ќекоторые компании не гибкие, поэтому подумайте, как эти два подхода будут комфортно сочетатьс€.

¬ы начинаете с упаковывани€ времени

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

 оманды самоуправл€ютс€

" то будет за всем этим следить?" - спросил  ит. ¬ы не можете полагатьс€ на то, что команды будут управл€ть собой сами, когда множество людей или множество ответвлений участвуют в проекте. Ћюд€м нужна едина€ точка контакта.

ќна растЄт вирусно

Ќе позвол€йте Agile распростран€тьс€ вирусно, предупредил  ит. ’от€ это может сработать дл€ некоторых вещей (например, прин€ти€ корпоративного вики), это не сработает с Agile. ” вас в конечном итоге останутс€ варианты, которые не работают, и не будет последовательного понимани€ того, что же такое Agile.

Ћюди наверху еЄ не понимают

Ёто очень реальна€ опасность, но € бы поспорил, что это проблема всех подходов к управлению проектами, а не только agile способа ведени€ дел. ≈сли у вас нет заинтересованного и понимающегоруководител€, то добитьс€ каких-нибудь изменений процесса или методологии будет очень трудно. ¬ы можете противосто€ть этой опасности путЄм усилени€ образовательной кампании, чтобы она касалась и этих руководителей, а также людей, которые будут непосредственно с ней работать.

»нструменты руковод€т переходом

 ит отметили это как опасность дл€ реализации Agile, но оп€ть-таки € считаю, что это угроза дл€ любого изменени€ в методологии. Ќе позвол€йте инструментам определ€ть переход к новому способу работы. »нструменты должны поддерживать ваши новые процессы, а не наоборот. ¬ случае Agile, не покупайте какое-то программное обеспечение дл€ поддержки разработки и затем не надейтесь, что оно "исправит" всЄ. ѕрограммное обеспечение не развЄртывает новые процессы - это делаете вы.

»сточник: pm4girls
–убрики:  менеджмент/agile

ћетки:  
 омментарии (0)

ƒокументаци€ Agile

ƒневник

¬торник, 23 Ќо€бр€ 2010 г. 11:10 + в цитатник
Agile больше ценит работающий софт, а не обширную документацию - это четвЄрта€ часть первичного манифеста. Ёто не означает "не пишите документацию"! Ёто ознначает "не пишите больше, чем необходимо дл€ документировани€". ” документации есть ценность, но сама практика документировани€ стала излишней - вот почему реакци€ на плохие примеры привлекла к себе внимание как один из краеугольных камней Agile.  ак же избежать чрезмерного сокращени€ документации при изменении культуры излишнего документировани€?

Ќеобходимость документировани€

ƒокументаци€ нужна нам, чтобы помочь нам общатьс€. ћожно определить команду Agile как "люди, создающие продукт". ћожно понимать под "создающие" людей, о которых мы обычно думаем как о предпринимающих действи€ по достижению цели, а можно расширить пон€тие и включить в команду и людей, имеющих цель.

— философской точки зрени€ Agile удел€ет особое внимание сотрудничеству. ќбычно оно происходит через (1) людей, которые предпринимают действи€ и работают сообща дл€ прин€ти€ наилучших решений и (2) людей, €вл€ющихс€ частью команды, которые сотрудничают с людьми, дл€ которых они создают продукт. ќбычно проекты, в разработке которых принимают участие заказчики, успешны, а те, в которых не принимают, - нет, поэтому лучше считать заказчиков частью команды.



¬не зависимости от определени€ сотрудничество требует коммуникаций, а коммуникации улучшаютс€ при наличии документации.

 оммуникаци€ во времени

 оммуникаци€ между группами людей происходит во времени.



Ќекоторое сотрудничество мгновенно - коммуникаци€ происходит пр€мо сейчас и важна пр€мо сейчас. ƒругие коммуникации более длительны - сотрудничество происходит пр€мо сейчас, но нам нужно будет помнить позже, о чЄм и почему мы договорились. —уществуют вариации "пр€мо сейчас" и различные степени "позже", но если упростить

- есть коммуникации дл€ сейчас
- есть коммуникации дл€ потом.

ќба вида важны.

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



Ёти массивные документы, меша€ разговору, всЄ-таки дают возможность запомнить (в будущем), почему мы прин€ли те решени€, которые прин€ли (сегодн€).

ƒокументаци€, как еЄ понимают в большинстве дискуссий agile, - случаи пользователей и критерии прин€ти€ или карточки, прикреплЄнные к стене, - не €вл€ютс€ хорошим решением дл€ коммуникаций, которые случаютс€ потом.



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

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

ћгновенные документы дл€ будущего

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

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



 ажда€ истори€ получила свою цветовую кл€ксу в верхнем левом углу, котора€ определ€ла кака€ из п€ти тем поддерживалась. Ќа изображении сверху вы можете видеть обведЄнными некоторые из них.

ћы также разработали набор из 8 прото-персон (прототипов, первый черновой вариант, очень грубое приближение персон - почти стереотипы), которых весь продукт / проект должен был поддерживать. ” каждой персоны была звЄздочка своего цвета.



” каждой пользовательской истории была сво€ наклейка в виде звЄздочки соответствующего цвета, котора€ показывала, дл€ какой персоны была написана истори€. ¬ частности, когда несколько персон могли использовать историю, мы определ€ли, дл€ какой персоны мы примен€ли историю на этом этапе.

¬ мире "пр€мо сейчас" эти ухищрени€ помогли нам пон€ть, поставить задачу и подтвердить темы и персоны, которые поддерживались в первой истории. Ёти разговоры помогли нам достичь прагматичных компромиссов относительно того, какие заказчики будут в выигрыше и когда. ќни также позволили нам написать исход€щее сообщение, что €вл€етс€ первым этапом в менеджменте ожиданий заказчиков.

—писок тем мен€лс€ в процессе - мы перешли с 4 до 5 тем, поскольку пон€ли, что нам лучше разделить одну тему на две. √руппа прото-персон выросла из первоначальных 3 до 8, поскольку мы быстро пон€ли, что команда пыталась "построить что-то дл€ каждого", а мы хотели избежать проблемы эластичного пользовател€ и вместо этого разработать возможности, которые бы удовлетвор€ли ценные группы пользователей с похожими цел€ми и перспективами.

»зменение культуры дл€ заказчиков

 ак и следовало ожидать, наличие кучи карточек, прилепленных к стене, даЄт команде замечательные, быстрые, "сейчас" коммуникации - как во внедрении, так и при общении. ќднако, карточки на стене - €вление краткосрочное. “акже это не лучший способ общени€ с заказчиками старой школы (представьте себе руководител€, который заставл€ет своих админов распечатывать е-мейлы, чтобы их читать и аннотировать - такие люди до сих пор существуют!).

Ёто может создать проблемы при сотрудничестве и коммуникаци€х с той частью команды, котора€ "не часть разработки".

¬ книге "ѕрименение пользовательских историй" ћайк  он делает ударение на том, что краткость пользовательских историй специально призвана побуждать (и € бы добавил "зависеть от") разговор. я считаю это как сильной, так и слабой стороной пользовательских историй. —ильной, потому что можно быстро охватить широкий круг тем (широта) и высветить несколько историй, как приведЄнный выше список. —лабой, потому что документаци€ требований не существует сама по себе - она требует разговора дл€ заполнени€ деталей. »ногда помогает использование тестов прин€ти€ "ѕроверь, что ..." в качестве метода документировани€ этих деталей (глубина) в сочетании с краткими, легко усваиваемыми истори€ми.

Ёти разговоры проходили как часть процесса определени€ историй, записи их на доске в правильном пор€дке и определении критери€ прин€ти€. ” заказчиков часто коротка€ пам€ть, особенно когда именно они шли на компромисс. Ќеобходим какой-то способ удержать контекст разговора, который привЄл к определЄнной организации и контенту историй на стене.

ѕосто€нные документы в насто€щем

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

ѕочему бы не применить тот же принцип интерктивной разработки к посто€нным документам?

–ассмотрим пример, приведЄнный выше, с использованием цветных наклеек в виде звЄздочек, которые определ€ли людей, к которым примен€лась кажда€ истори€ на каждом этапе. Ѕольша€ часть времени, потораченна€ на этот анализ, пришлась на понимание того, какие люди важны (дл€ успеха продукта) и дл€ каких людей возможность осуществлени€ этой пользовательской истории важна (дл€ персоны).  омбинаци€ этих двух важностей - начало приоритизации. ћинимальное количество времени было потрачено на прилепление стикеров к карточкам и на создание нескольких карточек дл€ одной и той же истории (кажда€ с разной наклейкой дл€ разных персон и потенциально разных критериев прин€ти€).

ƒобавьте немного нагл€дных пособий и создайте такую таблицу (или как вам удобнее).



¬ышеприведЄнна€ картинка показывает соответствие примеров использовани€ и действующих лиц. — такой же лЄгкостью она могла показать соответствие пользовательских историй и персон. ѕереход от мыслей о действующих лицах до мыслей о персонах короткий. Ёту таблицу € вз€л из более ранней статьи о распространении расписани€ с пользовательскими истори€ми - она помогает заказчикам получить общую картину кто когда выигрывает - пользовательскоцентрична€, но всЄ-таки вертикальна€ перспектива.

ѕримечание: ещЄ одним нюансом пошаговой доставки €вл€етс€ то, что вы можете представить "голую" версию истории сейчас, и "более хорошую" еЄ версию позже. ¬ы также можете показать, что истории со временем станов€тс€ лучше, дл€ некоторых пользователей, с помощью той же таблицы.

“акже очень просто составить таблицу, котора€ показывает, как кажда€ тема "представлена" на каждом этапе. “акой вид стимулирует хорошую дискуссию относительно того, стоит ли делать ударение сначала на одной теме, а затем на другой или нужно сначала сделать наиболее важные элементы в каждой теме - и постопенно добиватьс€ прогресса в каждой теме. —оздание такого вида и использование его дл€ коммуникаций помогло мне разрешить проблему, когда "внешние" заказчики считали, что команда выгл€дит "хаотичной и случайной" при еЄ подходе к приоритизации и внедрении.

ћножество моделей

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



 огда большинство людей жалуютс€ на документацию, они не жалуютс€ на вышеприведЄнную схему. ќни бы посчитали эту схему дополнением к разговору. ќтлично. ¬от что € сделал в своЄ врем€. «атем € еЄ сфотографировал. » вдруг она стала частью документации. ѕозже подошЄл заказчик, подтвердил, что системе следует работать таким образом, и подписалс€ на доске - и мы обновили фото.

 аждый т€жЄлый документ можно начать таким образом. » он может развиватьс€. ќн должен развиватьс€. ≈сли вы хотите добитьс€ успеха, он должен развиватьс€ по мере того, как ваша команда становитс€ умнее, ваши конкуренты реагируют и ваш рынок мен€етс€.

¬есь фокус в том, что вам не нужно писать окончательную версию прежде чем начать. «афиксируйте на высоком уровне, что вы знаете именно сейчас - как в дорожной карте. «афиксируйте достаточно деталей того, что вам нужно именно сейчас - как в бэклоге истории. » мен€йте еЄ по ходу.

«аключение

ƒокументаци€ - это не зло. ƒокументирование того, чем вы никогда не будете пользоватьс€, плохо. ƒокументирование того, что вам долгое врем€ не потребуетс€, рискованно, потому что оно может изменитьс€ до того, как вы обратитесь к своему документу.

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

»сточник: Tyner Blain
–убрики:  менеджмент/agile

ћетки:  

 —траницы: [1]