Сложные проекты: как избавиться от 80% проблем?

На слож­ных про­ек­тах про­блемы раз­но­об­разны: то нет ресур­сов, то сорвали сроки, то появи­лись непред­ви­ден­ные обсто­я­тель­ства. Но если при­смот­реться вни­ма­тель­нее, про­блема все­гда одна — люди. Точ­нее их ожи­да­ния.

Корень всех зол

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

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

Управляй мечтой

У меня есть мечта — управ­лять про­ек­тами без слез и боли. Это полу­ча­ется, когда кар­тинка в моей голове и в голове испол­ни­теля син­хро­ни­зи­ро­вана. Я жду дизайн к такому-то числу и испол­ни­тель знает, что я жду дизайн к такому-то числу. Если воз­ни­кают какие-то труд­но­сти, испол­ни­тель не пря­чется под стол, а зара­нее сооб­щает, что воз­никли такие-то труд­но­сти, по таким-то при­чи­нам и он соби­ра­ется сде­лать с ними то-то и то-то. Если от меня нужна какая-то помощь, будь то реше­ние, допол­ни­тель­ная инфор­ма­ция или ресурсы, он гово­рит мне, как только ощу­щает в этом потреб­но­сть (а не через неделю или месяц).

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

Ошибки коммуникации

Пого­во­рим о самых рас­про­стра­нен­ных убеж­де­ниях, кото­рые мешают орга­ни­зо­вать эффек­тив­ную команд­ную работу.

“Зачем ему сей­час об этом знать?!” Когда мы запус­кали свой пер­вый сайт, я рас­суж­дал так: сна­чала напи­шем тек­сты, потом сде­лаем дизайн, потом зака­таем в веб и только потом позо­вем сеош­ни­ков. Не надо им при­сут­ство­вать при старте про­екта. Это была ошибка. Когда при­шла пора раз­би­раться с seo, выяс­ни­лось, что не учтен целый ряд момен­тов на уровне раз­ра­ботки: у сайта не та струк­тура, не те адреса, не там исполь­зо­ван h1 и т.д. В резуль­тате потре­бо­ва­лись пере­делки, кото­рых можно было избе­жать. Поэтому лучше с самого начала выяс­нить у всех при­част­ных на каком этапе их сле­дует под­клю­чить к про­екту: на этапе обсуж­де­ния идеи, про­то­ти­пи­ро­ва­ния или дизайна, а не решать за людей, что им важно знать, а что нет.

“Зачем рас­ска­зы­вать о том, что мы сей­час делаем? Мы ведь от этого быст­рее рабо­тать не ста­нем, наоборот, потра­тим время на иди­от­ские отчеты”. Часто бывает, что испол­ни­тель делает работу, резуль­таты кото­рой нельзя пока­зать. Кодят сайт про­грам­ми­сты, иссле­до­ва­тели берут интер­вью, мар­ке­тинг-стра­те­гии рисуют интел­лект-карты и лепят сти­керы на доску. Время идет, резуль­та­тов нет и заказ­чик начи­нает нерв­ни­чать: “Чем все заняты? Что про­ис­хо­дит?” Муд­рый испол­ни­тель все­гда инфор­ми­рует заказ­чика о состо­я­нии про­екта. Это может быть теле­фон­ный зво­нок, две строчки в Скайпе или пол­но­цен­ный еженедельный/ежемесячный отчет — фор­мат нева­жен. Важно, чтобы заказ­чик был осве­дом­лен о том, что про­ис­хо­дит с про­ек­том и у него воз­ни­кала иллю­зия кон­троля над ситу­а­цией.

“Нельзя пока­зать дизайн, пока он не будет пол­но­стью закон­чен. Заказ­чик ничего не пой­мет и ска­жет: “Что это за ерунда? Что вы тут вообще дела­ете?” Еще одно вред­ное убеж­де­ние, кото­рое я обычно встре­чал у дизай­не­ров. Дей­стви­тельно, поиск реше­ния порой сво­дится к пере­бору вари­ан­тов: это не под­хо­дит, это тоже не под­хо­дит и это тоже — про­цесс может затя­нуться на несколько дней, а пока­зать как будто нечего. Однако именно этот про­цесс и важно пока­зать заказ­чику. Какие вари­анты рас­смот­рели и по каким при­чи­нам их отвергли. Это суще­ственно умень­шит риск при при­емке окон­ча­тель­ного макета, ведь когда дизай­неры пока­жут выстра­дан­ный резуль­тат, не факт еще, что он понра­вится заказ­чику.

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

“Не будем ничего про­яс­нять, сде­лаем точно как в тех­за­да­нии и точка”. Бывает так, что под­ряд­чик полу­чает тех­за­да­ние, кото­рое его сму­щает. Он мог бы пред­ло­жить более деше­вое и быст­рое реше­ние. Или ему кажется, что какой-то функ­ци­о­нал не слиш­ком важен с точки зре­ния пользы для биз­неса, зато его реа­ли­за­ция вле­тит в копе­ечку. Однако вме­сто того, чтобы про­яс­нить свои сомне­ния у заказ­чика, он думает: “Мне напи­сали сде­лать так, я сде­лаю так. Любой каприз за ваши деньги”.

Может пока­заться, что испол­ни­тель упро­щает себе жизнь, но в пер­спек­тиве он ее себе услож­няет. Когда заказ­чик уви­дит сметы или слу­чайно узнает, что было дру­гое, более удач­ное реше­ние, у него появятся вопросы: “А почему же вы не ска­зали, что можно иначе?” И хотя у испол­ни­теля будет фор­маль­ная отго­ворка: “Вы же сами напи­сали в тех­за­да­нии, делать так”, для заказ­чика она вряд ли про­зву­чит убе­ди­тельно.

“Нельзя гово­рить о про­бле­мах заказ­чику. Мы все должны испра­вить сами, чтобы никто не заме­тил”. Есть про­блемы, кото­рые команда должна и может решать сама — это про­блемы, с кото­рыми понятно что делать и есть ресурсы для их реше­ния. Однако если эти про­блемы при­во­дят к задержке про­екта о них важно и нужно инфор­ми­ро­вать заказ­чика. Дру­гая кате­го­рия про­блем тре­бует вме­ша­тель­ства заказ­чика, и замал­чи­вать их про­сто пре­ступно. Это ситу­а­ции, когда вскры­ва­ется допол­ни­тель­ный объем работ, либо команда ока­зы­ва­ется на рас­пу­тье, и непо­нятно какой путь пред­по­че­сть.

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

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

Как выстроить эффективное общение?

Пер­вое. Задача руко­во­ди­теля про­екта создать ком­форт­ную и без­опас­ную среду для всех участ­ни­ков про­екта. В конце кон­цов, люди не задают вопросы и замал­чи­вают про­блемы, потому что боятся, что им при­ле­тит по башке. Поэтому очень важно доне­сти мысль, что откры­то­сть и чест­но­сть при­вет­ству­ются (и поощ­рять их на деле), а вот попытка скрыть труд­но­сти, наоборот, кара­ется.

Вто­рое. Рас­пре­де­лить зоны ответ­ствен­но­сти между чле­нами команды. Это, в част­но­сти, озна­чает, что когда испол­ни­тель при­ни­мает задачу, в зоне его ответ­ствен­но­сти про­яс­нить все вопросы и пред­ло­жить наи­луч­шее реше­ние, а не про­сто фор­мально отра­бо­тать ТЗ. Здесь же важно опре­де­лить, какие вопросы испол­ни­тели будут решать между собой, а для каких при­зы­вать руко­во­ди­теля про­екта.

Тре­тье. Эффек­тив­ная ком­му­ни­ка­ция пред­по­ла­гает про­зрач­ные пра­вила вза­и­мо­дей­ствия, поэтому важно дого­во­риться о пра­ви­лах обще­ния. Напри­мер, уве­дом­лять друг друга о полу­че­нии писем. Вести пере­писку в системе управ­ле­ния про­ек­тами (wrike, basecamp и т.д). Согла­со­вы­вать делайны по про­ме­жу­точ­ным зада­чам. И т.д.

Проект без сюрпризов

Когда пра­вила обще­ния соблю­да­ются, то поло­вина про­блем исче­зает сама собой. Чтобы убить вто­рою поло­вину, надо регу­лярно сооб­щать руко­во­ди­телю проекта/заказчику, как обстоят дела с про­ек­том. Внутри команды это может быть реа­ли­зо­вано в виде регу­ляр­ных встреч или пере­писки в системе управ­ле­ния про­ек­том. Для заказ­чика в виде регу­ляр­ного отчета или пре­зен­та­ции. Такие кон­троль­ные точки важны как заказ­чику, так и испол­ни­телю. Заказ­чик видит, что работа дви­жется, испол­ни­тель же полу­чает цен­ную обрат­ную связь. Это поз­во­ляет выяв­лять ошибки по ходу дела и испра­вить без серьез­ных пере­де­лок про­екта.

При таком под­ходе заказ­чик и испол­ни­тель начи­нают чув­ство­вать себя соав­то­рами про­екта. Когда воз­ни­кают про­блемы, они не обви­няют в этом друг друга, а сов­местно ищут реше­ние.

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

В 99% слу­чаев для заказ­чика неприн­ци­пи­ально полу­чит он резуль­тат сегодня или через три дня. Но ему прин­ци­пи­ально важно, чтобы его ожи­да­ния и дей­стви­тель­но­сть не разо­шлись друг с дру­гом.

Если вы обе­щали закон­чить про­ект сегодня, а закон­чили через три дня — это может при­ве­сти к серьез­ным про­бле­мам. Если обе­щали через три дня и закон­чили через три дня — это вызо­вет только ува­же­ние и бла­го­дар­но­сть. Именно поэтому регу­ляр­ная сверка резуль­та­тов помо­гает осу­ще­ствить даже самый слож­ный и длин­ный про­ект без сюр­при­зов избав­ляет от 80% про­блем.