«Ну ма-а-ам… я більше так не буду», або Про веселе життя PM'а
[Від редакції: авторка попросила зберегти анонімність]
Себе я дуже люблю, і всю статтю можна було б присвятити самій лише розповіді про себе, але, думаю, це буде цікаво не всім. Усе, що вам треба про мене знати, — це те, що моя кар’єра в ІТ почалася з тестування, яке плавно перейшло в проджект-менеджмент. Мені було 19 — студентські роки, у які треба було виживати, тож уже майже 7 років варюся у сфері технологій. З цього можна зрозуміти, що я таки щось знаю.
Я ПМ без курсів/сертифікацій чи іншої освіти, за плечима лиш література, статті й переглянуті відео, тому все, що я знаю, — з особистого досвіду та практики. Люблю вичитати про якусь нову для мене фігню спробувати використати в реальному житті. Але дуже часто це все закінчується постмортемом...
Хочу поділитися досвідом, набутим у звичайних трудових буднях ПМ’а. Роботодавці вимагали підписаного договору про нерозголошення, тому імена підставні, а деталі проектів змінено.
Порожній тікет
Працюючи в аутсорсі, постійно треба засунути щось в зжаті ср*ки. Зранку прилітає завдання від замовника, яке треба зробити на вчора, бо за дві години демо й треба це показати інвесторам. Знайома ситуація?
І тут настає той момент, коли ти штампуєш завдання з одним тільки тайтлом, а суть розказуєш усно розробнику, навіть не тому, що тобі ліньки, а тому, що так банально швидше. У цьому разі тікет існує тільки для звітування часу.
Чим це погано? Уявіть, що вам треба зробити звіт чи зрозуміти, куди пішов час і чому. Ви відкриваєте завдання, яке створили місяць тому, а може, і більше. Без опису складно зрозуміти, про що взагалі йшлося. Тому краще витратити кілька хвилин, щоб описати завдання, ніж пізніше кілька годин чи навіть днів розбиратися в ситуації.
П’ятниця 17:00? — Час для деплою на прод
Я трохи мазохістка, це можна зрозуміти з професії, яку я обрала. І якщо ви теж полюбляєте гострі відчуття, рекомендую деплоїтися на прод у п’ятницю десь о 17:00 вечора, за годину до того, як усі підуть на довгождані вихідні.
У моїй практиці було такі два яскраві випадки. Але мушу також зауважити, що і вдалі релізи в п’ятницю в мене бували.
Кейс 1. Це була п’ятниця, кінець робочого тижня. На проекті працював фронтенд-розробник (віддалено, бо проживав у селі в Житомирській області). Був прекрасний літній вечір, і ніщо не віщувало біди. Чуваку доручили хотфікс на проді, щоб розмежувати стилі головного сайту і сайтів партнерів.
За півгодини до кінця робочого дня чувак скидає мерж, вимикає комп і йде працювати на комбайні у своєму селі. Його мерж приймають, ніяких критичних правок, тільки підключення ще одного CSS-файлу на проект. Спрацьовує автодеплой, і мені як менеджеру повідомляють, що все вигрузилось і можна сповістити замовника, що ми такі молодці та за кілька годин розв’язали проблему. Але я менеджер з досвідом, і перед тим як бігти до замовника, усе перевіряю. Я заходжу на головну сторінку й отримую біле простирадло без жодних признаків сайту.
В офісі залишився бекендер, який працював над проектом. А здавалося б, що могло піти не так? Але за законом Мерфі фронт не зібрався й сайт не запускався. Розробник недоступний, бо косить сіно комбайном (як ми пізніше дізналися), бекендер у паніці намагається відкотитися, а менеджер негодує. Та й узагалі, кажуть, є така прикмета, що як розізлити свого менеджера, то може й по шапці прилетіти.
Як ми це все розрулили, уже не пам’ятаю, але суть історії така: хотфікси в кінці робочого дня — не найкраща ідея, особливо якщо твій розробник — комбайнер :)
Кейс 2. Проект той самий і замовник той самий. Світло, камера, мотор! Напередодні Нового року команда закінчувала працювати над новим функціоналом для продукту. І якось так зірки на небі стали, що вдалося домовитися з начальством та отримати тиждень канікул з нагоди Нового року, тож ми були щасливі. Але треба, щоб і наші кастомери були не менш щасливі.
І от в останній день перед тим, як піти на канікули, телефонує замовник і просить зробити новорічний подарунок і вигрузити йому новий функціонал. Була дуже довга й скандальна дискусія з цього приводу. Функціонал не відтестовано, увесь наступний тиждень команда не працює, тож, якщо щось піде не так, ми не зможемо ні поправити, ні відкотитися. Але замовник усе-таки наполіг на своєму.
Угадаєте, хто дзвонив
Очевидне — не очевидне
Інколи очевидні нам речі не завжди очевидні для інших, і краще їх повторно проговорити, аби бути певним, що всі залучені особи — on the same page. Так само й замовникові якісь речі можуть здаватися очевидними, і тоді виникають ситуації: це ж стандартний функціонал, в усіх CRM воно є.
Дуже важливо зафіксувати всі домовленості листом чи контрактом, підписаним кров’ю, аби лише це було зафіксовано й у письмовому вигляді. Здавалося б, очевидна річ, але все ж не забувайте це робити й не лінуйтеся.
Бо буде щось типу: давайте додамо динозавра на головну, щоб він бігав справа наліво, коли скролиш сторінку (деяких своїх замовників я прямо запитувала, на що саме вони підсіли, якщо такі запити з’являються, але ніхто не ділиться). Намалювали ми того звіра, реалізували й залили в прод.
Минає місяць, і той самий чувак каже: «Я хотів не справа наліво, а зліва направо». А довести, що це чендж реквест можна, тільки якщо є письмова домовленість.
Перекомпоновка команди на проекті
Так виходить, що не завжди ви можете тримати девів на одному проекті всі 6 місяців розробки. Це зумовлено флоу компанії, у якій ви працюєте, а якщо це аутсорс, то це дуже поширена практика. Є проекти, які активно розробляють, а розробник до того веслував над іншим проектом, і його треба підтримувати. Прилітають правки, а разом з ними й твій колега-менеджер, і починає розказувати, чого їм на п’ятницю кров з носа треба зробити синю кнопку зеленою. А буває так, що проект різко закривають, бо замовник перестав фінансувати розробку.
Мій життєвий кейс. Розуміючи, що фаза дизайну добігає кінця, я збираю тімлідів і кажу, що за тиждень мені вже будуть потрібні заплановані під проект розробники. І якщо з бекендом не було проблем, то лід фронтів сказав, що вільного нікого немає, а найшвидше звільниться Пєтя, і це буде за
Я розумію, що ми дизайн настільки не затягнемо (і взагалі на фіксі немає, як щось тягнути, бо ті самі зжаті ср*ки й бюджети) і ставити проект на паузу немає можливості, бо нас чекає демо в кінці літа. Вирішили взяти людину з аутстафа. Це великий ризик, бо ніхто з нею ніколи не працював, ніхто не знає її реальний рівень, ніхто не розуміє її продуктивність. Але інших варіантів у нас не було.
У складі джуна-фронта, який тиждень тому вперше побачив Vue.js та аутстафера, який раніше писав на Angular, а не на Vue, ми починаємо розробку. Всі мої побоювання розвіялися за 3 тижні роботи, бо чувак виявився норм рівня, дуже відповідальним і вболівав за результат. Але біда прийшла, звідки її не чекали. Весна добігала кінця, коли мені подзвонив лід FE-розробників з повідомленням, що в нас два розробники на бенчі й треба їх чимось зайняти. Натяк був на те, щоб підключити їх двох на свій проект. Я запитала, що він узагалі курить, і звідки таке рішення.
Насправді на це були свої причини, і він усе-таки переконав мене, що ми можемо розпаралелити роботу на всіх. Я настояла, щоб ми принаймні відмовилися від аутстафа за таких розкладів. З лідом ми домовилися, що вся відповідальність за якість продукту на ньому, але чувак вдало звалив за два місяці, а мені залишалося з тим жити.
За такого складу ефективності взагалі не було, бо скоуп вони закривали не так швидко, як з’їдали бюджети. На жаль, нічим хорошим це не закінчилося: проект завершували вже як є, подекуди жертвуючи якістю й добре продуманою логікою, але все ж вийшли за межі бюджетів.
Тож, якщо флоу роботи компанії не дозволяє тримати стабільну команду на проекті, а у вас фіксований бюджет, врахуйте це в ризиках.
Тестування в кінці проекту
Учитися треба не тільки на своїх помилках, а й на чужих. Тобто лажаю в цьому житті не лише я (і, відверто кажучи, мене це тішить).
У колеги був випадок, коли не продали тестувальника на проект (проект по фіксу, відповідно був скоуп, бюджети й строки). Але де ж якість, якщо немає тестера? Працювали над проектом три місяці, розробляли демку для інвесторів, і ніхто це все не тестував... День Х наближався, залишалося менш як тиждень до релізу, підключили тестувальника, щоб хоч одним оком глянув, що робиться. Команда працювала всі вихідні й ніч перед релізом, щоб хоч щось адеквате вигрузити замовнику.
Тому, якщо волієте вночі поспати, а не багфіксити — підключайте тестера від початку проекту. Дотримуйтеся правила, що чим раніше знайшли баг, тим дешевше він коштує.
Т&М — не Т&М, якщо ви називаєте якісь суми замовнику
Прилітає сейлз-менеджер і каже, що потрібен раф естімейт проекту й що треба на ранок, бо вже домовилися із замовником? Ти в паніці бігаєш за тімлідами, щоб дали хоч якусь оцінку. «А що треба зробити?», — запитують тебе, а ти не знаєш, але треба на завтра. Якимось магічним чином усе-таки з’являється приблизний скоуп, його оцінюють пальцем у небо, і до кінця дня ти видаєш сейлзу число: 50к баксів. Говориш про все із сейлзом, кажеш, що це дуже приблизно й на це підписуватися не можна. Сейлз каже: та не парся, то ж Т&М.
Не знаю, що ті сейлзи далі роблять, але клієнт підписує контракт і починає з вами працювати. І ви підписалися на Т&М, і це ніби круто. Та є одне маленьке але... Ви назвали якусь суму замовнику, і він її запам’ятав на все життя. І ось ви почали працювати над проектом, унесли мільйон правок, тричі перемалювали дизайн... І в сумі вартість проекту вже не 50к, а 150. Але кого те взагалі гребе, ми ж за Т&М працюємо. А гребе це замовника, якому на початку вже назвали ціну. І його вже не гребе, що ми тричі змінили дизайн, бо ж казали 50к.
Тож попереджайте замовників, що правки скоупу впливають на вартість і строки проекту, та вимагайте від них письмового погодження, навіть якщо у вас Т&М.
Один розробник на проекті, і він іде у відпустку
Це, напевне, очевидно, але все ж... Поки це сам не переживеш, не зрозумієш увесь біль такої ситуації.
Довгий час у мене на підтримці був проект, за яким було закріплено фулстек розраба. І він любив у кінці літа сходити у відпустку й робив так щороку. Ну й запити за цим проектом приходили саме тієї миті, коли чувак звалював. Якщо це щось щодо нового функціоналу, то із цим немає проблем. Усе просто: пояснюєш, що ви це зробите пізніше, бо зараз немає кому.
Але одного разу на цьому веб-сервісі відвалилася платіжна система. Не те, щоб повністю: платежі проходили, але вони не доходили до бази самого сервісу, і відповідно користувач не міг отримати свій віртуальний товар, бо замовлення не оплачене.
Тож треба розібратися, і досить терміново, бо ризикуємо втратити користувачів. Підключаю я до завдання ліда розробників і ліда тестерів, бо бага виявилася ще й плаваючою. Лід розрабів каже, що потрібні доступи до логів і сервака, я біжу до девопса, а його немає на робочому місці, бо робочий день уже закінчився. Вибігаю до вхідних дверей: чувак уже перезувся й у літній легкій курточці, зі своїм чорним босівським пакетом у руках, відчиняє двері і піднімає ногу, щоб переступити поріг. Цієї миті я підбігаю, у паніці намагаюся щось пояснити, моя рєчь в той момент звучала приблизно так: «У нас проблеми, сервак, логи, не работає платьожка, там Іван і Степан, треба доступи...»
З такого набору слів він зрозумів, що все критично й не можна просто так піти додому. Злий девопс, який у вільний час цікавиться холодною зброєю, іде до свого місця, щоб дати розробникові доступ. Питання ми владнали того ж вечора, але я все ще боюся ходити темними вулицями міста, бо з таким хобі в чувака треба бути обережним.
Тож якщо така ситуація, то розробник обов’язково має передати проект комусь іншому на період відпустки, або хоча б ще один розробник у компанії повинен мати доступ до проекту для підстраховки в таких випадках.
Особливості ринку запуску проекту
Зробіть усе можливе, щоб ваша команда вас почула й знала, під який ринок ви пишете продукт. Упевніться в тому, що команда розуміє особливості предметної сфери й ринку, де буде запускатись проект.
Ми розробляли застосунок, у якому кількість екранів можна перерахувати на пальцях рук. Стартували з iOS-версії, і особливість була в тому, що запускати продукт планували в Азії й усі від початку це знали (мали б про це знати). За два місяці розробки ми виходили в перше бета-тестування. Застосунок протестували мільйон разів. Ми дуже чьотко вписувалися у співвідношення бюджету й скоупу, за строками навіть випереджали план, й у нас було кілька тижнів у запасі.
І от виходимо в бета-тестування, яке проходило в Китаї, де є особливість з китайфонами й обрізаним iOS SDK. У користувачів застосунок крешиться, тестування йде по одному місцю, замовник злий, менеджер у паніці, розробники в недоумєнії.
На щастя, ми мали логер-крашів, де бачили причини й могли їх оперативно виправляти, але це спричиняло додаткові витрати, які не передбачали на початку. Це навчило мене закладати особливості ринку в ризики. Крім того, можна більш детально прописувати в домовленостях, на яких саме девайсах ви гарантуєте стабільну роботу застосунку. А все, що не вказано, можна було б білити замовникові як додаткові роботи.
Почуття гумору
Я взагалі палкий прихильник шуточок і мемасів та вважаю, що без них ніяк. Але почуття гумору — це дуже тонка штука (особливо якщо ваші жарти пласкі). Не всі розуміють жарти, не всі можуть розпізнати сарказм і не всім притаманна самоіронія.
Почитали статтю й посміялися — добре... Але якщо мій роботодавець зрозуміє, чия це стаття, то завтра HR може покликати мене в кабінет і сказати, що я більше не працюю в компанії XYZ. Жарти жартами, але мене трохи не звільнили за мій гострий язик, тому треба знати міру (і в кожного вона своя). Перед тим як жартувати, треба розуміти аудиторію, і чи взагалі люди сприймуть усе правильно.
І насамкінець хочу сказати: не бійтеся ризикувати, використовувати нові методології й технології. Помилки — це нормально. Головне, робити висновки й рухатися далі. Ухвалюйте рішення й несіть за них відповідальність. Не всі рішення будуть правильні, але краще неправильне, ніж узагалі ніяке.
Це моя перша стаття, тому не судіть строго. Дякую тим, хто дочитав до кінця.
Ілюстрації Романа Кривенка
