Як будувати процеси молодій ІТ компанії | стартапу

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

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

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

З чого почати ?

Коли компанія починає зіштовхуватись із проблемами: *у мене зламався ноут, що робити?*, *коли там грейд | ревью?*, *коли у кого ДН?*. І більш технічні: *А як нам качати джунів?*, *чому ми стартуємо проект з 0, досі немає ніяких заготовок?*, *чому ти ребейзиш якщо я мержу ?*

Приблизно у цей момент вам потрібно створювати процеси і внутрішні документації.

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

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

Технічні та менеджрські процеси

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

Для Девелоперів:

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

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

3. Git - husky, також лінтери для найменування гілок. Гіт флоу мають знати всі розробники і притримуватись його.

4. Процес ревю коду, тут 2 аріанти: або один Тім лід який все дивиться або крос ревью коли всі дивляться код всіх, тут як зручніше. (Із власного досвіду скажу що на проектах де більшість девів джуни - ревювер має бути 1. Там де мідли і сенйори краще щоб ревювили один одного, так швидше будуть рости професійно)

5. Процес створення релізу, що куди і за чим мержити або ребезати, чи створювати тег-версію чи просто мержити у master(main).

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

   1. Посилання на свагер, api.

   2. Посилання на jira, redmine, asana

   3. Посилання на мікросервіси які взаємодіють.

7. Створення документації по проектах у redmine-wiki або jira-confluance де буде розписано які були релізи, і яка версія проекту була релізнута.

Для Лідів:

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

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

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

4. Створити гугл диск, чат в телеграм, гіт репозиторій із різними матеріалам: книгами, статтями, прикладами коду.

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

Для Дизайнерів:

1. Створити темплейт UI-Kit який можна перевикористовувати:

2. палітра

3. типографіка

4. базові компоненти

5. 1-2 сторінки

6. Проговорити із девами які моменти важливі для них при створенні леяутів по ваших дизайнах.

7. Промальовувати всі стани елементів: active, disabled, hover, focused, і т.п

8. Залишати у дизайнах референси на анімації для девів.

9. Створити документацію по принципах створення дизайну для нових дизайнерів:

   1. Яку сітку використовуєте.

   2. Які варіанти типографіки.

   3. Які принципи побудови палітри.

   4. Приклади шрифтів.

   5. Розміри елементів, тіні, заокруглення елементів.

Для Менеджерів:

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

2. Концепція сторі: User Story, Job Stories чи щось інше.

3. Воркфлоу - задача менеджера донести всім девелоперам, дизайнерам, QA який статус за яким іде і яка зона відповідальності кожного учасника процесу.

4. Документація по проектах, шаблони які мають бути:

   1. Документація де розписані всі посилання і доступи до цих ресурсів (логін - пароль, по типу login: [email protected]; password: test123).

   2. Документація по глобальних речах по типу - access control (різні юзери мають різні доступи на платформі, тому це має бути прописано і лінкуватись до задач де ці досткпи обмежуються в залаежності від ролі користувача).

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

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

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

Загальне:

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

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

І беріть активну участь у розробці процесів.

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

Підсумок

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

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

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