Организиране на работния процес в екип на IT проект

Здравейте, приятели. Постоянно, особено в аутсорсинга, виждам едно и също. Липсата на ясен работен процес в екипите по различни проекти.

Най-важното е, че програмистите не разбират как да комуникират с клиента и помежду си. Как да изградят непрекъснат процес на разработка на качествен продукт. Как да планират работния си ден и спринтовете.

И всичко това в крайна сметка води до пропуснати крайни срокове, извънреден труд, постоянни спорове кой е виновен и недоволство от страна на клиентите — накъде и как всичко се движи. Доста често всичко това води до смяна на програмисти, а понякога и на цели екипи. Загуба на клиент, влошаване на репутацията и т.н.

В своето време попаднах точно на такъв проект, където имаше всичките тези неприятности.

Никой не искаше да поеме отговорността за проекта (голям сервисен маркетплейс), текучеството беше ужасно, клиентът просто крещеше и се ядосваше. СЕО някак си дойде при мен и каза, че имам необходимия опит, ето ти картите в ръцете. Вземи проекта за себе си. Ако се провалиш, ще затворим проекта и ще уволним всички. Ще успееш, ще е страхотно, тогава ръководи го и развивай, както прецениш. В крайна сметка станах тимлидер на проекта и всичко легна на моите плещи.

Първото, което направих, е да разработя работен процес от нулата, който в момента отговаряше на моето виждане, и написах длъжностна характеристика за екипа. Имплементирането му не беше лесно. Но след около месец всичко се уреди, разработчиците и клиентът свикнаха и всичко тръгна тихо и комфортно. За да покажа на екипа, че това не е просто "буря в чаша вода", а реално решение на ситуацията, поех максимален обем задължения, сваляйки неприятната рутина от екипа.

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

Благодарение на този подход от наша страна, клиентът реши да поръча от нашата компания още един маркетплейс, което не може да не ни радва.

Тъй като на моя проект това работи, може би и на някого ще му помогне. И така, процесът, който ни помогна да спасим проекта:

Процесът на работа на екипа по проекта „Моят любим проект“

a) Вътрешен екипен процес (между разработчиците)

• Всички задачи се създават в системата Jira
• Всяка задача трябва да бъде описана максимално и да изпълнява строго едно действие
• Всяка функция, ако е достатъчно сложна, се разбива на много малки задачи
• Екипът работи по функциите като единична задача. Първо правим всички заедно една функция, предаваме я за тестване, след това взимаме следващата.
• Всяка задача се маркира, дали е за бекенд или фронтенд
• Има типове задачи и грешки. Трябва правилно да ги посочваме.
• След извършване на задачата, тя се прехвърля в статус преглед на кода (осъществява се пулл реквест към колега)
• Този, който е изпълнявал задачата, веднага следи времето си за тази задача
• След проверка на кода, ПР се одобрява и след това, този, който е изпълнявал задачата, самостоятелно я обединява в главния клон, след което променя статуса и я подготвя за деплой на дев сървър.
• Всички задачи, готови за деплой на дев сървъра, се деплоят от тимлид (неговата зона на отговорност), понякога от член на екипа, ако е нещо спешно. След деплоя всички задачи с готово за деплой на дев се прехвърлят в статус — готово за тестване на дев.
• Всички задачи се тестват от клиента
• Когато клиентът е тествал задачата на дев, той я прехвърля в статус готово за деплой на прод.
• За деплой на прод имаме отделен клон, в който обединяваме главния клон само преди деплой.
• Ако по време на тестването клиентът открие грешки, той връща задачата за доработка, установявайки й статус върната за доработка. Така отделяме новите задачи от тези, които не са преминали теста.
• В крайна сметка всички задачи преминават пътя от създаване до завършване: To Do → In Development → Code Review → Ready deploy to dev → QA on dev → (Return to dev) → Ready deploy to prod → QA on prod → Done.
• Всеки разработчик самостоятелно тестира своя код, включително и като потребител на сайта. Не се допуска обединяване на клона с основния, ако не се знае със сигурност, че кодът работи.
• Всяка задача има приоритети. Приоритетите се определят или от клиента, или от тимлида.
• Разработчиците в първия ред изпълняват приоритетните задачи.
• Разработчиците могат да назначават задачи помежду си, ако са намерили различни бъгове в системата или ако една задача се състои от работата на няколко специалисти.
• Всички задачи, създадени от клиента, попадат при тимлида, който ги оценява и или иска от клиента доработка, или ги назначава на един от членовете на екипа.
• Всички задачи, които са готови за деплой на дев или прод, също попадат при тимлида, който самостоятелно определя кога и как да се проведе деплой. След всеки деплой тимлидът (или член на екипа) трябва да уведоми клиента за това. Също така да смени статусите за задачите на готови за тестване на дев/прод.
• Всеки ден в едно и също време (при нас е в 12:00) провеждаме митинг между всички членове на екипа.
• Всеки на митинга отчитат, включително и тимлида, какво е направил вчера, какво планира да прави днес. Какво не се получава и защо. По този начин целият екип е наясно с това, кой с какво се занимава и на какъв етап е проектът. Това ни дава възможност да прогнозираме и коригираме, ако е нужно, нашите оценки и срокове.
• На митинга тимлидът също обявява всички промени в проекта и текущото ниво на бъговете, които не са намерени от клиента. Всички бъгове се разглеждат и назначават на всеки член на екипа за решаване.
• На митинга тимлидът назначава задачи на всеки, като отчита текущата заетост на разработчиците, нивото на тяхната професионална подготовка, а също и с оглед близостта на съответната задача до това, с което се занимава разработчикът в момента.
• На митинга тимлидът разработва обща стратегия по архитектурата и бизнес логиката. След което целият екип я обсъжда и взема решение за корекции или приемане на тази стратегия.
• Всеки разработчик пише код и изгражда алгоритми самостоятелно в рамките на единна архитектура и бизнес логика. Всеки може да изрази собственото си виждане за реализиране, но никой не може да бъде принуден да го направи само по определен начин. Всяко решение се аргументира. Ако има по-добро решение, но в момента няма достатъчно време за него, тогава се създава задача в JIRA за бъдещо рефактиране на определена част от кода.
• Когато разработчикът поеме задача, той я прехвърля в статус на разработка. Цялата комуникация относно уточняване на задачата с поръчителя лежи на плещите на разработчика. Техническите въпроси могат да се задават на тимлида или на колегите.
• Ако разработчикът не разбира същността на задачата, а поръчителят не успява да я обясни ясно, той преминава към следващата задача. А текущата задача се поема от тимлида, който сам обсъжда с поръчителя.
• Всеки ден разработчикът трябва в чата на клиента да пише по какви задачи е работил вчера и по какви задачи ще работи днес.
• Работният процес протича по скрам. Всичко е разделено на спринтове. Всеки спринт продължава две седмици.
• Спринтовете се създават, попълват и затварят от тимлида.
• Ако проектът има строг срок, се опитваме да направим естимация на всички задачи. И от тях сглобяваме спринт. Ако поръчителят се опитва да добави още задачи в спринта, тогава ние определяме приоритети и преносяме някои задачи за следващия спринт.

б) Процесът на работа с поръчителя

• Всеки разработчик може и трябва да комуникира с поръчителя.
• Не трябва да позволяваме на поръчителя да налага своите правила на игра. Трябва учтиво и дружелюбно да му дадем да разбере, че ние сме специалисти в нашата област и само ние трябва да изграждаме процесите на работа и да въвличаме поръчителя в тях.
• Необходимо е, в идеалния случай, преди да започнем реализацията на всякаква функционалност, да създадем блок-схема на целия логически процес за функцията (работен поток). И да я изпратим за потвърждение на поръчителя. Това се отнася само за сложна и неочевидна функционалност, например, платежна система, система за известия и т.н. Това ще позволи по-точно да разберем какво точно е необходимо на поръчителя, да запазим документацията за функцията, а също така да се застраховаме от това, че поръчителят в бъдеще може да каже, че сме направили нещо различно от това, което е искал.
• Всички диаграми/блок-схеми/логики и т.н. запазваме в Confluence/Jira, където молим клиента в коментарите да потвърди правилността на бъдещата реализация.
• Стремим се да не натоварваме клиента с технически подробности. Ако ни е нужно разбиране за това какво иска клиентът, рисуваме примитивни алгоритми под формата на блок-схеми, които клиентът може да разбере и сам всичко да поправи/доразвие.
• Ако клиентът намери бъг в проекта, молим да го опише много подробно в Jira. При какви обстоятелства е възникнал, кога, каква последователност на действия е извършвал клиентът при тестване. Молим да прикрепя скрийншотове.
• Стремим се всеки ден, максимум през ден да правим деплой на дев сървър. Клиентът тогава започва да тества функционала и проектът не остава без дейност. Освен това това е знак за клиента, че проектът е в пълна разработка и никой не му разказва приказки.
• Много често става така, че клиентът не до края разбира какво му е нужно. Тъй като създава нов бизнес, с все още неустановени процеси. Затова много често се случва ситуация, в която изхвърляме цели парчета код в кофата и преработваме логиката на приложението. От това произтича, че не трябва абсолютно всичко да се покрива с тестове. Има смисъл да се покриват тестове само критично важния функционал и то с уговорки.
• Има ситуации, когато екипът осъзнава, че не се вписваме в крайния срок. Тогава провеждаме бърз одит на задачите и веднага уведомяваме клиента за това. Като изход от ситуацията предлагаме да пуснем навреме важния и критичен функционал, а останалото да остане за пострелиз.
• Ако клиентът започне да измисля различни задачи от нищото, започне да фантазира и обяснява с жестове, молим да ни предостави макет на страницата и поток с логиката, която трябва напълно да опише поведението на целия макет и неговите елементи.
• Преди да поемем всяка задача, трябва да се уверим, че тази функция е била част от условията на нашия договор. Ако е нова функция, която излиза извън първоначалните ни споразумения, трябва задължително да я оценим ((приблизително време за изпълнение + 30%) х 2) и да уведомим клиента, че ще ни отнеме толкова време, плюс срокът за изпълнение се удължава с времето на оценката, умножено по две. Ако успеем да завършим задачата по-бързо — чудесно, всички ще спечелят от това. Ако не, сме се застраховали.

в) Какво не приемаме в екипа:

• Ненадеждност, разсеяност, забравяне
• „Хранене с обещания“. Ако не можеш да изпълниш задача, не знаеш как, трябва веднага да уведомиш тимлида, а не да чакаш до последно.
• Празни хвалби от човек, който още не е доказал своите способности и професионализъм. Ако е доказал, може, в рамките на приличието 🙂
• Лъжа във всякаква форма. Ако задачата не е изпълнена, не трябва да променяш статуса ѝ на завършена и да пишеш в чата на клиента, че е готова. Разбита компютър, срутена система, кучето е огризало лаптопа — всичко това е неприемливо. Ако настъпи истински форсмажор, тимлидът трябва веднага да бъде уведомлен.
• Когато специалистът постоянно е офлайн и е трудно да се свържеш с него по време на работа.
• Токсичност в екипа не се допуска! Ако някой е несъгласен с нещо, всички заедно се събират на среща и това се обсъжда и решава.

И още ред въпроси/тезиси, които понякога задавам на клиента, за да избегна недоразумения:

1. Какви са вашите критерии за качество?
2. Как определяте дали в проекта има проблеми или не?
3. Нарушавайки всички наши препоръки и съвети за промяна/подобряване на системата, всички рискове поемате само вие
4. Всички основни промени в проекта (например, всякакви екстра потоци) ще доведат до възможно появяване на бъгове (които естествено ще поправим)
5. Невъзможно е за няколко минути да разбереш какъв проблем е настъпил в проекта, а още по-малко веднага да го поправиш
6. Работим по конкретен продуктен поток (Задачи в Жира — Разработка — Тестиране — Деплой). А това означава, че не можем да реагираме на целия поток от молби и оплаквания в чата.
7. Програмистите са точно програмисти, а не професионални тестери, и не могат да осигурят необходимото качество на тестването на проекта
8. Отговорността за крайното тестване и приемането на задачите в продукция е изцяло ваша
9. Ако вече сме поели задача, не можем веднага да преминаваме на други, докато не завършим текущата (иначе това води до още повече бъгове и увеличаване на времето за разработка)
10. Хората в екипа станаха по-малко (поради отпуски или заболявания), а работата стана повече и физически не можем да реагираме на всичко, което искате
11. Вашата молба за деплой на продукция без тествани задачи в дев е само ваш риск, а не на разработчиците
12. Когато поставяте неясни задачи, без коректен флоу и без дизайнерски макети, това изисква от нас много повече усилия и срокове за изпълнение, тъй като вместо вас ни се налага да вършим допълнителна работа
13. Всякакви задачи за бъгове, без детайлно описание на възникването им и скрийншотове, не ни дават възможност да разберем какво е сбъркано и как да симулираме този бъг
14. Проектът изисква постоянно доработка и подобрения за повишаване на производителността и безопасността. Затова екипът отделя част от времето си за тези подобрения
15. Поради факта, че имаме надработки по часовете (спешни поправки), трябва да ги компенсираме в други дни

Обикновено, клиентът веднага разбира, че всичко не е толкова просто в разработката на софтуер и едно желание явно не е достатъчно.

Общо взето, това е всичко. Оставям зад кадър множество преговори и първоначалната настройка на всички процеси, но в крайна сметка всичко се наладило. Мога да кажа, че този процес стана за нас нещо като „Сребърна куршума“. Новите хора, които идваха в проекта, можеха да започнат работа още от първия ден, тъй като всички процеси са описани, а документацията и архитектурата под формата на диаграми веднага дават представа за това, с което се занимаваме.

P. S. Искам да уточня, че на наша страна няма проектен мениджър. Той е на страната на клиента. Напълно не технически. Проектът е европейски. Цялата комуникация е само на английски.

На всички успех в проектите. Не се изтощавайте и се опитайте да подобрите процесите си.

Изходният код е в мен блога си..

Източник: habr.com