Highway to release: Шлях проєкту з юніорами, замість сеньйорів

Чому варто брати юніорів в проєкти?

Чому мене цікавить це питання? Зайду трохи здалеку. Я досить давно в IT-індустрії, побував на різних посадах, починаючи з hardware інженера, software інженера, тімліда, project-менеджера, product-менеджера, маркетолога. Сьогодні моя позиція - senior solution architect в GlobalLogic і я досить добре уявляю, як влаштована IT-індустрія. До того ж, веду власні курси програмування, тож я розумію роботу з юніорами й специфічні особливості цього процесу.

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

А як взагалі буває?

Для початку, подивимося, які типи контрактів в outsourcing програмуванні існують.  

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

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

Time and materials

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

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

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

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

Йдемо далі. Ви добре попрацювали, проєкт повинен зростати. Вам потрібні нові розробники. Де їх взяти? Знову шукати сеньйорів?

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

Будуємо процес

Як же побудувати роботу юніорів? А ось як!

Дивіться, ось спрощена схема. Є експерт. І є у нього прайд, яким він керує.

Хто такий експерт?

По-перше, експерт веде pre-sale активність з замовником. Це фахівець, який технічною мовою може обговорити проєкт з замовником і переконати його, що він зможе зробити його.

По-друге, він solution архітектор. В результаті він повинен буде побудувати або схвалити архітектурне рішення.

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

І четверте, що він повинен робити - це швидко читати код і аналізувати, що зроблено юніорами, аби відловлювати та виправляти їх помилки.

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

А що такє прайди?

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

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

Які нові артефакти SCRUM будуть присутні в цій моделі?

Planning робиться тільки експертом. Він оцінює складність завдання.

Grooming - може робитися разом з командою.

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

Де це працює? Моделі fixed price або outsource - замовнику не показують, хто робить завдання, як він це робить. Тільки експерт, який був присутній в pre-sale демонструє прогрес і спілкується з замовником.

Stand-up.

Stand-up складається з 2-3 мітингів експерта в день з кожним прайдом. Перший meeting це - head meeting, головний мітинг, де експерт визначає завдання для прайду. Останній мітинг - це перевірка результату. Протягом дня може бути ще один проміжний, для контролю або коригування процесу.

Максимум в одного експерта може бути до 4-х прайдів.

День експерта виглядає так:

• 4 head мітинга - 2 години
• 4 middle мітинга - 3 години
• 4 фінальних мітинга - 2 години

Разом, набігає 8 годин “без обіду". Плюс ще треба щось зробити самому, плюс спілкування з замовником. Що це означає? Що це унікальна роль, зазвичай близька до керівника компанії або експерт сам керівник. 

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

Head мітинг. Постановка задачі та її опис. Це можуть бути матеріали для вивчення. Наше завдання - крім здачі проєкту, ще й виростити юніорів. Обов'язковий елемент - перевірка розуміння. Недостатньо просто запитати у юніорів - зрозуміли? Вони скажуть - зрозуміли! В такому випадку експерт повинен поставити питання, які покажуть реальну картину. Як на співбесіді. 

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

Серединний мітинг або Middle мітинг.

Він призначений для коригування або уточнення завдання. Наприклад, для аналізу обраного юніорами рішення.

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

Будуємо прайди

Як будуються самі прайди? Як вони покращуються в процесі роботи?

Перш за все необхідно пам'ятати:

В середньому розраховуйте на 30% звільнення юніорів. Як робиться відсів? Потрібно збирати метрики. На підставі цих метрик в принципі й робиться такий відсів.

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

І в чому вигода?

Є два моменти: фінансова і побічна.

Спочатку про гроші. Розраховуйте вашу кількість спеціалістів та їх ефективність з розрахунку, що прайд повинен мати ефективність у 35% від сеньйора. Інакше це не працює. 

Як цього досягти?

• Маленькі задачі
• Юніори в змозі їх виконати
• Вони розуміють, що від них вимагається
• Експерт контролює їх діяльність

Перейдемо до непрямої вигоди.

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

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

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

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

• Заощадити на найманні сеньйорів. Заощадити як гроші, так і час.
• Отримати у своє розпорядження юніорів, які професійно ростуть.
• Успішно скласти проєкт в термін в моделі outsource.

Автор: Дов Німрац, Senior Solution Architect, Consultant, GlobalLogic Ukraine.