SCRUM для социальных проектов: чему можно поучиться у разработчиков программного обеспечения

Communication in Scrum projects
Communication in Scrum projects
По согла­сию редак­то­ра бло­га, мы пере­во­дим ста­тью Хан­ны Кейн, опуб­ли­ко­ван­ную на сай­те Idealist.org в апре­ле это­го года. Это пер­вая часть из трех ста­тей, в кото­рых рас­кры­ва­ют­ся сек­ре­ты из мира раз­ра­бот­ки про­грамм­но­го обес­пе­че­ния, кото­рые могут успеш­но при­ме­нять­ся в сфе­ре соци­аль­ных тех­но­ло­гий. Пер­вая часть рас­ска­зы­ва­ет о рас­по­зна­ва­нии про­блем на пути к дости­же­нию цели.

Автор: Хан­на Кейн. Пере­вод: Вале­рий Ильи­чев

Я рабо­таю в коман­де раз­ра­бот­ки про­ек­та Idealist. На моей визит­ной кар­точ­ке напи­са­но «SCRUM-мастер»(читается как “СКРАМ-мастер”), что зву­чит немно­го страш­но и мистич­но (на самом деле, это не так страш­но). Одна из моих основ­ных задач — устра­не­ние про­блем в коман­де веб-раз­ра­бот­чи­ков.

«SCRUM» – это одна из попу­ляр­ных «гиб­ких» мето­до­ло­гий сов­мест­ной раз­ра­бот­ки слож­но­го про­грамм­но­го обес­пе­че­ния. «Гиб­кий» про­цесс поз­во­ля­ет опи­сы­вать слож­ные про­ек­ты как набо­ры про­стых задач, объ­еди­няя послед­ние с помо­щью инже­нер­ных прин­ци­пов и мето­дов внут­ри­ко­манд­но­го обще­ния.

Узна­вая боль­ше про гиб­кие мето­до­ло­гии и SCRUM в част­но­сти, я откры­ла мно­же­ство воз­мож­но­стей той рабо­ты, кото­рой коман­да Idealist зани­ма­ет­ся еже­днев­но. Но мож­но ли при­ме­нять ана­ло­гич­ные тех­ни­ки в соци­аль­ных про­ек­тах, таких как иско­ре­не­ние нище­ты, реше­ние про­блем без­дом­ных людей или даже собра­ния миро­вых лиде­ров при обсуж­де­нии кли­ма­ти­че­ских изме­не­ний ?

Техника распознавания проблем

Каж­дое утро мы начи­на­ем с 15-минут­но­го собра­ния (назы­ва­е­мо­го «еже­днев­ный SCRUM»), на кото­ром раз­ра­бот­чи­ки рас­ска­зы­ва­ют о пла­ни­ру­е­мых на день зада­чах и обсуж­да­ем воз­мож­ные про­бле­мы их реше­ния. Одна из исполь­зу­е­мых нами тех­ник — созда­ние спис­ка слов, кото­рые могут ука­зы­вать на скры­тую про­бле­му, напри­мер это сло­ва «попро­бую», «воз­мож­но», «наде­юсь».

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

Такое выяс­не­ние — не моти­ва­ция в сти­ле маги­стра Йоды («делай или не делай, ника­ких попы­ток»), а воз­мож­ность всем понять, что имен­но вызы­ва­ет затруд­не­ния. Ско­рее все­го, это скры­тая про­бле­ма вро­де того, что раз­ра­бот­чик не совсем разо­брал­ся в той части кода, кото­рую он изме­ня­ет. Как толь­ко про­бле­ма выве­де­на на поверх­ность, коман­да начи­на­ет рабо­тать над её устра­не­ни­ем — воз­мож­но, объ­еди­нив рас­сказ­чи­ка в пару с раз­ра­бот­чи­ком, име­ю­щим боль­ше опы­та в дан­ной части кода.

Приложения для изменения мира?

Опре­де­ле­ние сто­я­щих на вашем пути (или пути вашей орга­ни­за­ции) пре­пят­ствий — это клю­че­вой шаг в любых пла­нах по изме­не­нию мира. Вот несколь­ко стра­те­гий:

  • Делай­те это регу­ляр­но

В SCRUM при­ня­то еже­днев­но обсуж­дать про­бле­мы, с кото­ры­ми столк­ну­лась коман­да. Для вашей орга­ни­за­ции, воз­мож­но, это будет еже­не­дель­ный риту­ал, или обсуж­де­ние на полу­го­до­вом собра­нии ваших сотруд­ни­ков.

  • Учи­тесь рас­по­зна­вать скры­тые про­бле­мы

В мире веб-раз­ра­бо­ток суще­ству­ет несколь­ко ука­за­те­лей на скры­тые про­бле­мы: оста­нов­ка раз­ви­тия, появ­ле­ние мно­же­ства задач «в про­цес­се завер­ше­ния», выход сбой­но­го кода. В мире соци­аль­ных задач ука­за­те­ля­ми могут быть: неудач­ная фанд­рай­зин­го­вая ком­па­ния, про­пу­щен­ный еже­год­ный отчет, полу­че­ние нега­тив­ных отзы­вов от кли­ен­тов. Научи­тесь рас­по­зна­вай­те такие (и подоб­ные) симп­то­мы, это при­зна­ки суще­ство­ва­ния скры­тых про­блем.

  • Делай­те скры­тые про­бле­мы види­мы­ми

Неко­то­рые SCRUM-коман­ды исполь­зу­ют «Дос­ки пре­пят­ствий», на кото­рых содер­жат­ся кар­точ­ки с опи­са­ни­ем встре­чен­ных в про­ек­те про­блем. Кар­точ­ка про­бле­мы появ­ля­ет­ся на дос­ке при рас­по­зна­ва­нии про­бле­мы и сни­ма­ет­ся с дос­ки, как толь­ко про­бле­ма устра­не­на. Визу­а­ли­за­ция про­бле­мы дела­ет её види­мой для всех, что созда­ет тен­ден­цию для её ско­рей­ше­го реше­ния.

  • Рас­став­ляй­те про­бле­мам при­о­ри­те­ты

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

  • Раз­де­ле­ние ответ­ствен­но­сти

Хоро­ший SCRUM-мастер помо­га­ет коман­де в реше­нии про­блем, созда­вая куль­ту­ру раз­де­ле­ния отвест­вен­но­сти. Ана­ло­гич­но, испол­ни­тель­ный дирек­тор или про­ект-мене­джер может быть един­ствен­ным отвест­вен­ным за реше­ние всех про­блем орга­ни­за­ции, но при гра­мот­ном назна­че­нии отвест­вен­ных из чис­ла чле­нов коман­ды про­бле­мы реша­ют­ся более быст­ро.

В рабо­те над Idealist мы обна­ру­жи­ли, что повы­шен­ное вни­ма­ние к опре­де­ле­нию и реше­нию про­блем силь­но уве­ли­чи­ва­ет нашу про­из­во­ди­тель­ность. А что дума­е­те вы? Есть ли у вас хит­ро­сти и сек­ре­ты в поис­ке и реше­нии про­блем вашей орга­ни­за­ции или про­ек­та?

Фото: Peter Hellberg