Як організувати подію і радіти життю. Частина 2. Побудова команди

Привіт, мене звати Андрій і це друга стаття з серії в якій ми з командою ділимося досвідом організації подій і всього-всього.

Якщо ви не читали першої частини, то це не біда, ви можете її прочитати зараз або пізніше. В ній мова йшла про інструменти, а в цьому матеріалі мова піде про головне  — команду.

Організовуючи хакатон AngelHack у мене був ряд обмежень в плані людей. Перше — більшість моїх креативних і перевірених друзів були залучені у організацію фестивалю de:coded, разом з яким відбувався наш захід. Друге — я вирішив не висмикувати команду бетаплейсу з основної роботи, тому що там у нас також була діяльність та інші події.

Як результат: велика нагода і в той же час виклик — команду потрібно було збирати з нуля.

Як утворюються команди?

Як це узагалі відувається? Не залежно від того чи проект комерційний чи громадський. Природньо — спершу ви шукаєте у ближньому колі своїх знайомих. Потім виходите на знайомих-знайомих, потім далі, і в результаті можна дійти до зовсім незнайомих людей з вулиці.

Починаючи проект у мене було приблизне уявлення ролей в команді події, і було розуміння що розподіл цих ролей і кінцевий результат буде напряму залежати від людей що зберуться.

Етап розкрутки події:

  • Координатор / трафік-менеджер
  • Робота з медіа та соц-мережами, залучення учасників
  • Фандрейзинг та робота з партнерами, залучення спонсорів
  • Робота з контентом події, залучення менторів та судей
  • Дизайн та візуальне оформлення усього
  • Технічна підтримка, веб-сайт та інше

Підготовка заходу:

  • Логістика
  • Організація та декорування простору
  • Робота з волонтерами
  • Технічне забезпечення події
  • Фак-ап менеджмент

Як ці ролі розподіляти — немає універсальних відповідей. Є конкретні випадки які залежать від конкретних людей.

Важливе правило: команді потрібно чітко розуміти хто що робить. Персонально я коли чую що людина описує свої обов’язки як “структурую, стратегую та продумую” — то це означає що вона не робить нічого і команді не потрібна.

Кожен повинен приносити конкретну і видиму користь проекту, а стратегія, організація та продуманість це результат командної роботи а не однієї людини.

Наступний принцип який для себе я визначив що стосується будь якої роботи— команда може працювати або в офісі, або розподілено, але в жодному разі не можна робити щоб частина була постійно онлайн а частина постійно офлайн. Це докорінно руйнує взаємодію, губиться ритм роботи або ж витрачається дуже багато ресурсів на підтримку такої гібридної структури.

Також важливо визначити часові рамки для роботи вашої команди, чи це фул-тайм проект, чи парт-тайм і хто скільки часу йому приділяє. Для розподілених чи парт-тайм команд потрібно визначити графік зустрічей чи принаймні групових дзвінків.

Віддалена робота ефективна лише у добре організованих та вмотивованих людей або при надзвичайно жорсткому процесі, який знову ж таки накладає зайвий оверхед. Так чи інакше — в короткій перспективі оренда офісу обійдеться дешевше ніж забезпечення цих умов.

Як я раніше казав — початковий склад команди у нашому випадку був 5 людей. 

Основною загрозою, яку неможливо швидко виправити власними ресурсами я бачив шанси не зібрати достатню кількість людей, тож на комунікації залучив аж двох.

В результаті, першочерговий розподіл виявився таким:

  • Андрій (я)— трафік менеджмент, робота з angelhack комунікація з менторами та суддями, закривання дірок.
  • Валя — Робота зі спонорами, фандрейзинг
  • Варя — Робота з медіа-партнерами
  • Макс — Комунікації з учасниками
  • Женя — дизайн, тех-підтримка

По ходу проекту до нас ще долучились Дмитро, Софія та Володя.

Однією з цікавих і як на мене хороших особливостей нашої команди було те, що в команді було щонайменше двоє людей, які володіли спільними навичками і могли один одного підмінити.

Таким чином — Максим та Варвара могли повністю заміняти один одного, те ж стосувалося мене і Валентини. При потребі я міг зайнятися технічною частиною, а в Жені був досвід фандрейзингу.

Таке накладання умінь та навичок необхідно закладти при підборі команди, воно збільшує вашу ударо-стійкість і згальну продуктивність та креативність. Мати декілька поглядів на одну проблему завжди добре, якщо ви вмієте слухати одне одного та домовлятися.

У літературі цей підхід описаний як противага підходу MECE mutually exclusive and collectively exhaustive, при якому кожен елемент системи, чи член колективу володіє унікальним набором навичок і в сумі вони подібно пазлу формують суцільну картину.

Застосування принципу заміщуваності дозволяє команді не випадати з процесу якщо хтось йде у відпустку, або не може працювати за інших обставин (у нас було три ситуації коли один з членів команди повністю випадав на 2–3 тижні, в тому числі і координатор).

Тут слід відійти в бік ліричного відступу і подумати про те, що ж таке ідеальна команда.

Ми живемо у час високої компелксності, і це означає що одна людина не здатна самотужки здійснити інновацію, чи створити щось дійсно проривне. Усі успіхи та досягнення про які ми читаємо у соц-мережах та новинах це результат роботи команд.

Саме команда — це найменша ефективна одиниця сучасного суспільства, бізнесу та навіть військової справи.

Хороший доказ цьому описаний у книзі “Teams of Teams” де розглядається еволюція менеджменту і ситуація коли начебто супер-ефективна, потужна військова машина США не могла впоратися з погано підгтовленими, відверто бідними терорестичними угрупуваннями Аль-Каіда. Американці почали досліджувати їхню структуру і згодом провели реструктуризацію одного з найбільш просунутих своїх підрозділів у систему аналогічну до мусульманського угрупування. Де на зміну жорсткій ієрархії та системі аналіз-планування-виконання, в якій кожна функція належить окремій ланці організації прийшла мережева структура команд максимально інтегрованих та натренованих діяти спільно і водночас приймати рішення самостійно, орієнтуючись по ситуації.


 

Google свого часу провела масивне дослідження тривалістю в два роки. Під нього був створений окремий відділ, метою якого було базуючись на надзвичайно великому об’ємі даних яким володіла компанія визначити якості команди чи групи, які корелюють з результативністю їх роботи.

 

 

Якщо коротко, вони не знайшли майже нічого. Кожна команда індивідуальна і будується по іншому.

‘We had lots of data, but there was nothing showing that a mix of specific personality types or skills or backgrounds made any difference. The ‘‘who’’ part of the equation didn’t seem to matter.’

Та все ж є три показники які чітко вирізняють команди серед інших, менш ефективних груп людей (колективів)

мовою оригіналу вони звучать так:

  1. “equality in distribution of conversational turn-taking.’’
  2. “average social sensitivity’’ 
  3. “shared belief held by members of a team that the team is safe for interpersonal risk-taking.’’ 

Інтерпретувати їх можна наступним чином:

  1. Команди в яких під час обговорень та дискусій учасники займають приблизно рівну долю ефіру є більш ефективними за ті де є чітко виражені “лідери” розмови і ті хто весь час мовчить.
  2. Соціальна чутливість — це властивість людей відчувати один одного в групі, у кого поганий настрій, що відчувають та як сприймають інформацію інші члени команди та враховувати ці фактори у своїх діях та висловлюваннях.
  3. Здатність брати ризики та відповідальність за інших. “Колективна відповідальність” напротивагу “Груповій безвідповідальності” котра практикується у багатьох колективах. Провали сприймаються не як вина конкретної особи а як недопрацювання усієї групи, незалежно від того наскільки добре кожен виконав свою частину.

Чинником, який дозволяє вищеперечисленим явищам розвинутися та відбутися є персональна довіра між окремими членами команди. Немає універсальних засобів її створення, але є речі які цьому сприяють.

Базуючись на тому ж дослідженні можна сказати що команди, які окрім основної робочої активності проводять спільно час, розмовляють на відірвані теми і спілкуються як живі люди, а не безликі офісні працівники-професіонали, мають значно вищий рівень довіри і як наслідок продукують набагато кращі результати в плані креативності та ефективності.

Саме тому важливі не лише професійні навички але й людські якості і сумісність членів групи. У цьому полягає сенс спільних обідів, прогулянок, виїздів та гулянок, і в нормальної “здорової” команди вони відбуваються самі собою, для цього не потрібно штату HR-ів, натужних корпоративів та менеджерів радості. 

Звісно, для декого це дослідження не несе принципово нової інформації, це той самий “common sense” обгрунтований фактами та цифрами. Та деколи свідоме розуміння процесів дозволяє реагувати на потенційні загрози значно швидше, задовго до їх появи.

Одним із інструментів чи фреймворків яким ми користувалися для того щоб прискорити процес перетворення колективу у команду був Team Canvas.

Team Canvas

http://theteamcanvas.com/

Це фреймворк оформлений у вигляді таблиці подібної за своєю сутністю до Business Model Canvas, але призначеної для формування команди та направлення її у напрямку мети.

Таблиця розділена на 9 секцій, які повинен заповнити кожен учасник (деякі індивдуально, деякі за спільною згодою). Правильно поставлені запитання і у правильному порядку дозволяють швидко зрозуміти вузькі точки у комунікації та вивести команду на спільний рівень розуміння проекту.

Ось ці пункти:

  1. Ролі та відповідальності
  2. Спільні цілі
  3. Особисті цілі
  4. Мета
  5. Цінності
  6. Сильні сторони та ресурси
  7. Слабкі сторони та ризики
  8. Потреби та очікування
  9. Правила та активності

Зповнювати канву найкраще у формі вокршопу, коли усі учасники збираються разом та пишуть відповіді на запитання на стікерах чи таблиці, та шляхом діалогу приходять до консенсусу по запитаннях які вимагають колективного бачення (спільні цілі, мета).

На сторінці http://theteamcanvas.com/use/ детально описано як заповнювати її, але найкраще якщо ваш процес фасилітуватиме людина знайома з фреймворком, щоб відповідати на запитання і роз’яснювати деякі з пунктів.

TeamCanvas доречно застосовувати :

  • При запуску проекту і формуванні команди
  • Коли команда зайшла в глухий кут і потрібно перезавантажитися, згадати початкову мету
  • При залученні нових людей у проект
  • Регулярно раз на 2–3 місяці для того щоб корегувати курс, куди рухається проект

В документації написано що типова сесія триває 90–120 хвилин, хоча з мого досвіду зазвичай процес розтягується на 2–3 години.

Давайте детальніше пройдемося по пунктах. Роз’яснення і приклади можна знайти у офіційному туторіалі, я радше опишу чому кожен з них важливий і що він дає.

Заповнюючи канву усі члени команди повинні бути максимально чесними та відкритими, вже на цьому можна побачити рівень довіри у команді і її потенціал для успіху чи провалу.

Найзручніше роздрукувати канву на великому аркуші паперу (А2 або А1), запастися різнокольровими стікерами та ручками, так щоб кожному учаснику дістався інший колір чи їх комбінація (червона ручка на зеленому папері, синя на фіолетовому і т.п.).

Фасилітує процес або лідер команди або ж людина ззовні. Його завдання — зачитувати пункти, роз’яснювати їх а також слідкувати за таймінгом та модерувати дискусії.

Поїхали!

Люди та ролі — простий на перший погляд пункт, який дозволяє відповісти на питання, без якого деякі проекти живуть роками. Хто за що відповідає?

В цьому пункті кожен учасник повинен описати свої відповідальності, оголошені та фактичні, і решта членів команди повинні погодитися з цим. Дуже часто, особливо після кадрових змін колектив не розуміє, хто що робить і чим займається, нерідко це стає причиною конфліктів. Якщо кожен вголос окреслить свою зону відповідальності то це суттєво спростить усім життя, а також дозволить побачити частки проекту за які не відповідає ніхто .

Спільні цілі — Пункт, в якому команда має дійти згоди що до спільної мети. Чого ми хочемо досягти? Дуже добре якщо цей пункт буде оформлений згідно критеріїв SMART. Що точніше і детальніше описана ціль, то простіше потім буде виміряти результативність проекту.

Індивідуальні цілі — Кожен описує чого він хоче досягти в рамках проекту. Персональний розвиток, кар’єрний ріст, самореалізація. Цей пункт дозволяє розкрити мотивацію кожного члена команди, і як наслідок допомогти йому у її втіленні.

Мета — візійне запитання “Навіщо ми це робимо?”, “Що змушує нас кожен день прокидатися і займатися цим проектом?”, це мабуть чи не найважчий пункт і те наскільки швидко ви дійдете розуміння по ньому і свідчитме наскільки добре ваша команда усвідомлює що вона робить. На відміну від спільної цілі яка є конкретною, мета може бути абстраткним результатом її досягнення, яким чином світ стане кращим завдяки вашим старанням?

Цінності — ще один надзвичайно важливий пункт. Кожен член команди спершу виписує свої індивідуальні цінності а потім ми намагаємося знайти спільний знаменник, який буде зрозумілий і прийнятий усіма.

Сильні сторони та ресурси — кожен виписує і озвучує свої сильні сторони, професійні навички та м’які скіли, які він готовий привнести у команду так само як і ресурси доступні до залучення. Тут важливо бути максимально відкритим і не боятися включити якісь неважливі на перший погляд речі. До прикладу ви можете бути хорошим дизайнером, але окрім цього КМС з плавання та смачно готувати плов. Усе це може стати в нагоді.

Слабкі сторони та області що потребують розвитку — один з найважчих пунктів, який потребує максимальної відкритості. Тут не потрібно займатися самобичуванням, а просто дати команді знати, що ви можете бути дратівливим, чи можете на тиждень раптово зникнути і не виходити на зв’язок, чи у вас є сім’я, яку потрібно забезпечувати і наявність стабільного доходу є для вас критичною. Обмін такою інформацією формує як довіру в команді, так і її міцність по відношенню до внутрішніх та зовнішніх загроз.

Потреби та очікування — перелік матеріальних і ментальних потреб, без яких ви не зможете працювати в рамках проекту. Смачна кава? Вільний графік? Спільні обіди чи можливість бути на самоті? Що дозволить кожному з учасників максимально проявити свої сильні сторони і убезпечитися від описаних раніше загроз?

Правила та активності — Процесуальні побажанння, правила що утворилися впродовж цієї сесії, які ми б хотіли зафіксувати в проекті. Тут же можна обговорити і онлайн інтсрументи взаємодії.

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

На моєму досвіді вже 4 проекти в яких було застосовано цю методологію, і один з них проходження воркшопу врятувало від краху, а іншому дуже суттєво спростило запуск і скоротило період притирання.

Сподіваюся наш досвід буде корисним і вам, тож підписуйтеся на наш фейсбук та твіттер щоб не пропустити наступний пост.

Also read...