Побудува процесингу ніколи не у проіоритеті у новій компанії тому що кількість людей мала і для менеджменту не потрібно бугато ресурсів. Також комунікація більш не формальна тому що всі добре знають один одного.
Але це все починає валитись у момент коли кількість людей у компанії стрімко зростає. Втрачається принип *всі добре знають один одного* і якщо до цього моменту не було побудовано процесів то буде хаос.
Буду розповідати більше із технічної сторони. Які процеси будувались і чому це не так просто як може здаватись.
З чого почати ?
Коли компанія починає зіштовхуватись із проблемами: *у мене зламався ноут, що робити?*, *коли там грейд | ревью?*, *коли у кого ДН?*. І більш технічні: *А як нам качати джунів?*, *чому ми стартуємо проект з 0, досі немає ніяких заготовок?*, *чому ти ребейзиш якщо я мержу ?*
Приблизно у цей момент вам потрібно створювати процеси і внутрішні документації.
Перші питання із технікою, ревью та івентами - вирішується CRM системою. І внутрішня CRM система це зазвичай проект який майже кожна ІТ компанія створює сама, тому що у кожної компанії є свої вимоги і першочергові потреби які потрібно закрити, не обов*язково тягнути супер круту CRM із підпискою за мільйон грошей щоб знати коли у Віті день народження.
Також до цього відноситься і те як нараховуються лікарняні та відпустки, чи можна їх перенести на наступний рік. Чи є система бенифікації за активність. Чи є рефанди за англійську, спорт зал і т.п.
Не буду розписувати ці аспекти, тут все дуже ситуативно, але це потрібно проговорювати і заносити у внутрішні документації
Технічні та менеджрські процеси
Ці процеси в значній мірі відрізняються, але багато в чому схожі. Тож будувати одні процеси без інших просто не можливо, Дочитавши до кінця зрозумієте як побудови одних процесів спростять життя при побудові інших.
Для Девелоперів:
Процес розвертяння проекту (це має бути швидко), мають бути готові приклади або boilerplate із готовими реалізаціями для авторизації, роутингу, роботи з апі (для фронтенду) ну і майже те саме для бекенду.
Лінтери та приттери, має бути винесено окремим репозиторієм або як gist-page, Код стайл загалом не має відрізнятись на одній і тій же технології на різних проектах, це прискорить процес заміни людей не проектах, тому що все в одному стилі.
Git - husky, також лінтери для найменування гілок. Гіт флоу мають знати всі розробники і притримуватись його.
Процес ревю коду, тут 2 аріанти: або один Тім лід який все дивиться або крос ревью коли всі дивляться код всіх, тут як зручніше. (Із власного досвіду скажу що на проектах де більшість девів джуни - ревювер має бути 1. Там де мідли і сенйори краще щоб ревювили один одного, так швидше будуть рости професійно)
Процес створення релізу, що куди і за чим мержити або ребезати, чи створювати тег-версію чи просто мержити у master(main).
По кожному проекту має бути заповнений README.md де буде написано що потрібно щоб запустити цей проект, які версії пакетів мають бути і за якими посиланнями знаходиться дев-стенд та прод, також які енвайрмент змінні та інші ситуативні аспекти:
Посилання на свагер, api.
Посилання на jira, redmine, asana
Посилання на мікросервіси які взаємодіють.
Створення документації по проектах у redmine-wiki або jira-confluance де буде розписано які були релізи, і яка версія проекту була релізнута.
Для Лідів:
Створення ревью документації, бажано по рівнях, також ця документація має опиратись на цілі компанії, тобто якщо ваші проекти в більшості стартапи то вам потрібено качати стек технологій на яких це робиться швидше за все.
Можливо, не зразу, але з часом допомагати створювати персональні плани розвитку для людей які просідають у цих моментах.
Процес для технічної співбесіди. Запитання, критерії відбору, ви повинні знати який рівень людей потрібен щоб підсилити колектив.
Створити гугл диск, чат в телеграм, гіт репозиторій із різними матеріалам: книгами, статтями, прикладами коду.
Розробити темплейт для внутрішніх призентацій, який можна зможуть використовувати інші люди, у якийсь момент компанія дійде до проведення внутрішніх мітапів, і цей темплейт вам дуже допоможе.
Для Дизайнерів:
Створити темплейт UI-Kit який можна перевикористовувати:
палітра
типографіка
базові компоненти
1-2 сторінки
Проговорити із девами які моменти важливі для них при створенні леяутів по ваших дизайнах.
Промальовувати всі стани елементів: active, disabled, hover, focused, і т.п
Залишати у дизайнах референси на анімації для девів.
Створити документацію по принципах створення дизайну для нових дизайнерів:
Яку сітку використовуєте.
Які варіанти типографіки.
Які принципи побудови палітри.
Приклади шрифтів.
Розміри елементів, тіні, заокруглення елементів.
Для Менеджерів:
jira це ваше поле бою, але не тільки. Випрацюйте механізм оцінювання задач, або це години або сторіпоінти або ще якісь ведмеді.
Концепція сторі: User Story, Job Stories чи щось інше.
Воркфлоу - задача менеджера донести всім девелоперам, дизайнерам, QA який статус за яким іде і яка зона відповідальності кожного учасника процесу.
Документація по проектах, шаблони які мають бути:
Документація де розписані всі посилання і доступи до цих ресурсів (логін - пароль, по типу login: test@test.com; password: test123).
Документація по глобальних речах по типу - access control (різні юзери мають різні доступи на платформі, тому це має бути прописано і лінкуватись до задач де ці досткпи обмежуються в залаежності від ролі користувача).
Проводьте ретро, тут не потрібна документація, це має бути як процес який є у компанії, навіть якщо все добре - проводьте хоч раз на місяць.
У кожного учасника команди має бути чітке розуміння того хто за що відповідає, ваша задача доносити це до людей.
Ніколи не довіряйте розробникам, завжди перевіряйте те що вам говорять.
Загальне:
Якщо ви займаєте високі посади у компанії то ви повинні розуміти що люди відрізняються і комусь буде потрібно іноді поговорити, а хтось буде сидіти у 4х стінах і писати код. Тому очікувати однакового рівня розвитку від всіх людей - не правильно. Мотивувати людей потрібно в міру, але не давати сильно розслаблятись, якщо за 1-2 роки у людини немає ніякого прогресу, то на це не потрібно забивати, краще це обговорити - дізнатись причину і або залишити як стабільну людину яка добре знайома із принципами компанії, або знайти заміну.
Розробіть для себе конкретне розуміння зони відповідальності різних людей і позицій, це значно спростить роботу у майбутньому. Не просіть у менеджера технічну документацію по проекту - зразу йдіть до ліда.
І беріть активну участь у розробці процесів.
Якщо ви новачок і прийшли у компанію де нічого із того що я писав вище немає то спробуйте знаходити для себе відповіді на ці запитання. І якщо з часом вони не закриються то краще змінити компанію бо хаосом складно керувати.
Підсумок
Я розповів про процеси які мені довелось створювати або приймати участь у створенні.
Можливо, вам не потрібно все із того що я написав, у різних компаній - різні цілі, тому створюйте процеси під себе, але не забувайте що це важлива складова розвитку вашої компанії.
Всі процеси і пункти які я описував зрозумілі по заголовках, але насправді майже про кожен пункт можна написати окрему статтю, думаю, у майбутньому так і буде. Тож слідкуйте за оновленнями.
