Як набрати в ІТ-стартап команду розробки, яка дійсно зробить продукт?

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

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

Частина I. Ризики
В ідеальній ситуації розробка нового продукту виглядає так: ви набираєте людей, описуєте їм ваш продукт так, як ви його бачите, і називаєте термін. Команда йде працювати і в потрібний момент приносить готовий якісний продукт, який потім потроху (але також швидко і якісно) доопрацьовує.

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

  1. Фатальне затягування термінів. Продукт розробляється і навіть виходить якісним, тільки от або вікно можливостей закрилося, або бюджет закінчився.
  2. Стабільно неякісний продукт. Продукт готовий і випущений, клієнти прийшли, але вони постійно стикаються з проблемами при використанні вашого продукту. А команда тиждень за тижнем, місяць за місяцем не може забезпечити їм нормальну роботу. Клієнти не витримують і йдуть до конкурентів, або в нікуди.
  3. Трудомістка реалізація нових вимог. Клієнти стоять у черзі (деякі – навіть з пачкою грошей) з проханнями додати нові можливості, але чомусь доопрацювання відбувається дуже повільно. Або на серйозних обсягах даних через рік після старту всі раптом стало працювати дуже-дуже повільно, і ніхто не знає, як швидко вирішити проблему (а клієнти лають вас останніми словами і йдуть). Загалом, мова йде про низький «внутрішньому» вашого продукту: невдала архітектура, відсутність тестів на критичні блоки коду, складні внутрішні залежності – все це не дозволяє з прийнятною швидкістю розвивати продукт і боротися за клієнтів.
  4. Втрата працездатної команди. В якийсь момент ключові фахівці (особливо, якщо такий фахівець один) можуть раптово вирішити, що їм цікавіше працювати в іншій компанії, а то й зовсім потрапити під трамвай. Буває, що залишилася команда виявляється не в змозі не тільки розвивати, але і навіть підтримувати продукт з прийнятною якістю. А кандидати на співбесіді дивляться в повні туги очі потенційних колег, потім в код, і більше не виходять на зв'язок.


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

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

Реалізація будь-якого з цих ризиків і навіть поєднання декількох – не вирок для продукту і бізнесу. Як правило, можна прикласти зусилля і повернути свій продукт на рейки сталого розвитку. Особливо, якщо компанія вже пристойно заробляє. Але витрачені час і гроші не підуть на розвиток, клієнти будуть все це час чекати рішення своїх проблем, і у конкурентів з'явиться фора. Профілактика ж набагато дешевше, ніж лікування. Ось про неї і поговоримо.

Частина II. Кваліфікація і мотивація
Будь-який розробник (втім, це стосується і інших фахівців, залучених до розроблення) володіє двома дещо умовними, але дуже важливими параметрами. Це кваліфікація та мотивація.

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

Опишемо чотири крайніх випадки:

  1. Найвища кваліфікація, зашкалюває мотивація. Це неспинний Творець. Він ефективний і лаконічний. Завжди знає, що робить, тому що все це вже робив. Працює цілодобово, тому що його вставило.
  2. Найвища кваліфікація, мотивація пішла в мінус. Теж всемогутній, йому нічого не потрібно. Дещо як вирішує термінові завдання, але треба примушувати і контролювати.
  3. Ніякої кваліфікації і ніякої мотивації. Стереотипний студент з профільною освітою, який на вході в професію хоче велику зарплату, але попрацювати за неї тільки два місяці в році.
  4. Ніяка кваліфікація, але зашкалюває мотивація. Людина шалено енергійний, освоює нове і навчається. Але за ваш рахунок. Здійснює всілякі помилки, частина з яких виявляється негайно, а частина вистрілить потім. Пожирає час більш досвідчених колег (якщо вони є) питаннями, контролем та виправленням помилок.


Обидва ці параметра не постійні в часі.

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

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

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

Трохи докладніше про кваліфікації
Кваліфікацію можна розкласти на декілька складових:

  1. Технічна кваліфікація – це знання своїх інструментів (алгоритмів, мов, платформ і середовищ розробки, купи фреймворків та бібліотек, програм для роботи дизайнера або тестувальника і так далі), а також навички їх ефективного застосування.
  2. Досвід – це знання про те, як потрібно діяти в тих чи інших ситуаціях. Його можна отримувати на своїх помилках (наприклад, коли розробник сам написав кілька багатопоточних додатків і наступив на всі основні граблі) або на чужих (наприклад, попрацювати в команді высоконагруженного рішення і зблизька побачити, як ці помилки роблять інші). Цінність досвіду – в можливості на шляху до мети уникнути помилок, які можуть дорого обійтися вашого продукту і бізнесу.
  3. Навички взаємодії – це вміння ефективно вибудовувати взаємодію з оточуючими: колегами, користувачами, клієнтами. Сюди входить і вміння чітко формулювати думки, і атмосфера взаємодопомоги в команді, і відповідальність за якість своєї роботи, і турбота про кінцевих користувачів, і здатність настояти на своєму, якщо буде потрібно. Таку кваліфікацію, мабуть, придбати найважче. Напевно, тому її часто називають культурою.


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

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

І навпаки, коли базовий рівень мотивації високий, загальна ефективність співробітників (особливо в частині взаємодії) буде набагато вище. Падінь «в нуль» уникнути все одно не вдасться (хоча б із-за накопичення втоми), але це не буде повсякденним режимом.

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

Так чого ж ми хочемо від співробітників і команди?
Все дуже просто. Якщо ви хочете, щоб ваш проект провалився не з-за проблем з розробкою, а на більш пізньому етапі (і тим більше, якщо хочете, щоб він вистрілив), потрібно:

  1. На всі позиції набирати тільки людей достатньої кваліфікації;
  2. Забезпечити їм високу базову мотивацію;
  3. щодня контролювати поточну мотивацію.


Частина III. Вибір людей. Правильно і неправильно
І так, нам потрібні кваліфіковані люди. Тобто люди, які не тільки технічно підковані і досвідчені, але ще й будуть готові продуктивно працювати разом. Де ж їх взяти?

Як правильно
Набирайте людей з досвідом і з щепленням правильної культури. Зазвичай це люди з досвідом 5+ років, які помітне час попрацювали у великих та середніх компаніях, про які ви знаєте, що там все в порядку з культурою. Культура в нашому випадку – це коли не прийнято ні за яких обставин робити гівно (змиримося з тим, що це фактично загальноприйняте формулювання в нашій області), всередині команд панує атмосфера співпраці, компанія та її співробітники відкриті сучасним підходам до організації ефективної роботи і так далі. Загалом, почесна роль великих і середніх IT-компаній – готувати вам співробітників. А оскільки вони досить великі, непогані розробники, які застрягли в професійному, кар'єрному або зарплатному зростанні, там обов'язково будуть. Ось вони-то вам і потрібні.

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

Як неправильно
Наймати в команду стратапа людей без досвіду (вчорашніх студентів, сьогоднішніх стажистів), людей з in-house розробки і маленьких компаній, що займаються замовний розробкою (якщо, звичайно, у них немає досвіду, описаного вище).

У них не буде або досвіду і світогляду, що дають змогу приймати правильні рішення (наприклад, в частині прогнозування обсягів даних, навантаження, організації модульності і separation of concerns), або культури ефективної роботи в команді (відповідальності, навичок планування і всякого agile, design and code review, тестування та написання тестів, і так далі).

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

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

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

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

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

Вам не треба шукати і наймати людей, все компетенції вже підібрані, підрядник випробуваний. Але його інтерес полягає в тому, щоб заробляти гроші, а не робити для вас якісний продукт максимально ефективно, і кожна помилка, яка веде до переробок в майбутньому – це не проблема для підрядника, а додаткові гроші (адже головне закрити поточний етап, так?). Але якщо продукт все одно приречений, це не страшно. А ось якщо продукт раптом абсолютно несподівано стає прибутковим, то у підрядника може виникнути питання: а чи не занадто дешеві його послуги, та і взагалі, чий це насправді продукт.

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

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

Спрощено кажучи, розробник (тестувальник, дизайнер, интерфейсолог, верстальник, тимлид) працює в одному з трьох режимів: «самореалізація», «працюю за зарплату», «чекаю, коли мене звільнять». І абсолютно всі люди переключаються між цими режимами базової мотивації в різні періоди свого життя.

В режимі самореалізації людина працює над вашим проектом як над своїм. Вболіває за проект, поглядає вперед, а не лише собі під ноги, допомагає товаришам. Ну і чого гріха таїти, хоче затягнути нову технологію, випробувати новий підхід або переробити все з нуля. Але взагалі, в цьому стані будь-який член команди в рази продуктивніше, ніж у двох інших (тут ми пропонуємо читачеві ознайомитися з класичною працею Фредеріка Брукса «Міфічний людино-місяць», якщо він раптом ще не знайомий із ним). І команда в цілому теж може працювати в такому собі турборежимі. У цьому випадку команда навіть підтягує «випадають» учасників до загального рівня. В певних межах, звичайно.

У режимі «працюю за зарплату» теж немає нічого надто поганого, при наявності почуття відповідальності. Людина не горить, але зате його продуктивність стабільна. Він робить тільки «від і до», але зате він робить «від і до» добре. І з чистою совістю йде додому шість. У цьому режимі людина може непогано робити свою роботу, але у нього вже немає мотивації вдивлятися в майбутнє, продумувати потенційні проблеми, до яких призведе те чи інше рішення, а головне – серйозно боротися за те, щоб рішення приймалися правильні, якість продукту було високим, а темп розробки відповідав потребам бізнесу.

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

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

Давайте зрозуміємо, як цього домогтися.

Як правильно
Наша мета – зібрати досвідчених розробників (тестувальників, дизайнерів, верстальників, аналітиків) з великих і середніх IT-компаній, з досвідом і високим рівнем «виробничої культури». А потім підтримувати у них максимально ефективний режим роботи.

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

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

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

Отже, що ви можете запропонувати вашій майбутній команді:

Залучення в продукт
Почніть з перспектив продукту. Ми ж припускаємо, що у вас вже є продумана ідея, бачення і все таке. Якщо ви хочете, щоб ваша команда працювала в режимі «самореалізації», " продайте їй ваш продукт. Ніхто не робить з ентузіазмом явне УГ.

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

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

Ви забираєте до себе досвідчених професіоналів, тому зарплата (з урахуванням премій) повинна бути вище ринкової.

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

По-друге, ви говорите вашому співробітнику: «Ми розуміємо цінність співробітників, ви – наш ключовий актив, ми хочемо і готові платити нашим співробітникам вище ринку (це важливо для підтримання режиму самореалізації») і при цьому очікуємо, що вони будуть працювати відповідним чином. Ми не готові платити менше співробітникам, які працюють гірше – ми не можемо дозволити собі таких співробітників. І ми не можемо платити більше, тому що такі витрати не дозволять бізнесу злетіти».

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

Заодно відразу ж закриємо питання про те, чи потрібно пропонувати частку в бізнесі. Так склалося, що ситуація в Росії відрізняється від ситуації в США в цьому питанні дуже сильно. Там стартапи не можуть конкурувати в плані грошей з найбільшими компаніями галузі, зате пропонують мрію – опціони на випадок зльоту. У нас все рівно навпаки – стартапи з бюджетом і продуманим планом розвитку за рахунок маленької ефективної команди можуть дозволити собі платити трохи більше ринку. А на обіцянки частки у світлому майбутньому нікого не купиш: надто вже сумна статистика. При цьому пропонувати частку в бізнесі людям, з якими ще не зварено каші, в Росії елементарно небезпечно: корпоративний конфлікт на будь-якому етапі може поховати всі починання. Опціони ж у нас поки толком не працюють.


По-третє, досить високі зарплати дозволяють, як було відмічено вище, обґрунтовано вимагати від співробітника певного рівня ефективності. Це стане важливим, коли буде потрібно (а цей момент обов'язково настане, і не раз) змінити сформовані умови роботи, змінити бізнес-процеси. Для всіх, кого торкнуться зміни, це буде вихід із зони комфорту, тому без тиску керівника або ззовні команди справа не обійдеться. Якщо зміни принесли користь, розумні люди врешті-решт погодиться з ними, але без проміжного конфлікту все одно не обійтися. І в цьому випадку правильна матеріальна мотивація – важлива страховка від втрати цінних працівників.

Відповідальність
Питання відповідальності – ключовий в розробці програмного забезпечення і для команди, і для бізнесу. Якщо об'єктивно завдання вимагає тиждень робочого часу, а керівник вимагає вирішити її за два дні і не слухає ніяких аргументів, то в 99% випадків результатом будуть погано виконані вимоги і гірка заметених під килим проблем. Розробник буде змушений зробити гівно (ми пам'ятаємо, що спеціально набирали людей, яким робити гівно фізично неприємно), а проблеми, заметені під килим, обійдуться в години або тижня затримок в майбутньому. Мотивація впала, проблеми з'явилися. Саме тому критично важливо, щоб оцінка роботи виходила від членів команди. За неї не можна торгуватися, формулювати завдання більш детально, коригувати вимоги (привіт, agile), але остаточну оцінку має дати людина, який буде її виконувати. Тому що оцінка завдання – це акт прийняття на себе відповідальності за терміни і якість вирішення цієї задачі. Правильність оцінки вимагає досвіду, а взяття на себе відповідальності вимагає культури. Саме ці вимоги до членів команди і ми сформулювали у другій частині статті.

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

Наприклад, затримка зарплати без попередження всього на день – мінус «мотиваційну» карму. Раптова зміна вимог по середині ітерації без зрозумілих вагомих причин? Мінус в карму. Колега отримує стільки ж, скільки ти, але працює упівсили, і ніхто нічого не робить вже два місяці? Мінус в карму. Нового співробітника такого ж рівня беруть на таку ж позицію з зарплатою в півтори рази вище? Все одно це стане відомо – мінус в карму. Завжди прощали прострочений на день дедлайн, а в цей раз строго у відповідності з домовленістю зменшили премію? А все одно мінус в карму. Обіцяли премію на чітких умовах, а потім «об'єктивно, немає грошей, щоб стільки заплатити»? Вам цього не забудуть.

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

Як неправильно
Просто не ставитеся до команди розробки як одному з найбільш цінних активів.

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


Не «звітуйте» перед командою. Адже якщо подумати, то яке розробникам справу до того, як йдуть продажі? Тримайте обговорювані з клієнтами нові функції в секреті від команди до останнього. Заодно завжди в два рази зменшити для команди терміни появи функцій, які ви узгодили з клієнтами.

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

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

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

У наступній частині
У наступній статті ми розглянемо питання організації роботи команди – теж з позиції мінімізації ризиків. Не перемикайтеся.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.