«Ну ма-а-ам... я більше так не буду», або Про веселе життя PM’а

[Від редакції: авторка попросила зберегти анонімність]

Себе я дуже люблю, і всю статтю можна було б присвятити самій лише розповіді про себе, але, думаю, це буде цікаво не всім. Усе, що вам треба про мене знати, — це те, що моя кар’єра в ІТ почалася з тестування, яке плавно перейшло в проджект-менеджмент. Мені було 19 — студентські роки, у які треба було виживати, тож уже майже 7 років варюся у сфері технологій. З цього можна зрозуміти, що я таки щось знаю.

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

Хочу поділитися досвідом, набутим у звичайних трудових буднях ПМ’а. Роботодавці вимагали підписаного договору про нерозголошення, тому імена підставні, а деталі проектів змінено.

Порожній тікет

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

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

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

П’ятниця 17:00? — Час для деплою на прод

Я трохи мазохістка, це можна зрозуміти з професії, яку я обрала. І якщо ви теж полюбляєте гострі відчуття, рекомендую деплоїтися на прод у п’ятницю десь о 17:00 вечора, за годину до того, як усі підуть на довгождані вихідні.

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

Кейс 1. Це була п’ятниця, кінець робочого тижня. На проекті працював фронтенд-розробник (віддалено, бо проживав у селі в Житомирській області). Був прекрасний літній вечір, і ніщо не віщувало біди. Чуваку доручили хотфікс на проді, щоб розмежувати стилі головного сайту і сайтів партнерів.

За півгодини до кінця робочого дня чувак скидає мерж, вимикає комп і йде працювати на комбайні у своєму селі. Його мерж приймають, ніяких критичних правок, тільки підключення ще одного CSS-файлу на проект. Спрацьовує автодеплой, і мені як менеджеру повідомляють, що все вигрузилось і можна сповістити замовника, що ми такі молодці та за кілька годин розв’язали проблему. Але я менеджер з досвідом, і перед тим як бігти до замовника, усе перевіряю. Я заходжу на головну сторінку й отримую біле простирадло без жодних признаків сайту.

В офісі залишився бекендер, який працював над проектом. А здавалося б, що могло піти не так? Але за законом Мерфі фронт не зібрався й сайт не запускався. Розробник недоступний, бо косить сіно комбайном (як ми пізніше дізналися), бекендер у паніці намагається відкотитися, а менеджер негодує. Та й узагалі, кажуть, є така прикмета, що як розізлити свого менеджера, то може й по шапці прилетіти.

Як ми це все розрулили, уже не пам’ятаю, але суть історії така: хотфікси в кінці робочого дня — не найкраща ідея, особливо якщо твій розробник — комбайнер :)

Кейс 2. Проект той самий і замовник той самий. Світло, камера, мотор! Напередодні Нового року команда закінчувала працювати над новим функціоналом для продукту. І якось так зірки на небі стали, що вдалося домовитися з начальством та отримати тиждень канікул з нагоди Нового року, тож ми були щасливі. Але треба, щоб і наші кастомери були не менш щасливі.

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

Угадаєте, хто дзвонив 2-го січня з проханням відкотитися? :)

Очевидне — не очевидне

Інколи очевидні нам речі не завжди очевидні для інших, і краще їх повторно проговорити, аби бути певним, що всі залучені особи — on the same page. Так само й замовникові якісь речі можуть здаватися очевидними, і тоді виникають ситуації: це ж стандартний функціонал, в усіх CRM воно є.

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

Бо буде щось типу: давайте додамо динозавра на головну, щоб він бігав справа наліво, коли скролиш сторінку (деяких своїх замовників я прямо запитувала, на що саме вони підсіли, якщо такі запити з’являються, але ніхто не ділиться). Намалювали ми того звіра, реалізували й залили в прод.

Минає місяць, і той самий чувак каже: «Я хотів не справа наліво, а зліва направо». А довести, що це чендж реквест можна, тільки якщо є письмова домовленість.

Перекомпоновка команди на проекті

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

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

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

У складі джуна-фронта, який тиждень тому вперше побачив Vue.js та аутстафера, який раніше писав на Angular, а не на Vue, ми починаємо розробку. Всі мої побоювання розвіялися за 3 тижні роботи, бо чувак виявився норм рівня, дуже відповідальним і вболівав за результат. Але біда прийшла, звідки її не чекали. Весна добігала кінця, коли мені подзвонив лід FE-розробників з повідомленням, що в нас два розробники на бенчі й треба їх чимось зайняти. Натяк був на те, щоб підключити їх двох на свій проект. Я запитала, що він узагалі курить, і звідки таке рішення.

Насправді на це були свої причини, і він усе-таки переконав мене, що ми можемо розпаралелити роботу на всіх. Я настояла, щоб ми принаймні відмовилися від аутстафа за таких розкладів. З лідом ми домовилися, що вся відповідальність за якість продукту на ньому, але чувак вдало звалив за два місяці, а мені залишалося з тим жити.

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

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

Тестування в кінці проекту

Учитися треба не тільки на своїх помилках, а й на чужих. Тобто лажаю в цьому житті не лише я (і, відверто кажучи, мене це тішить).

У колеги був випадок, коли не продали тестувальника на проект (проект по фіксу, відповідно був скоуп, бюджети й строки). Але де ж якість, якщо немає тестера? Працювали над проектом три місяці, розробляли демку для інвесторів, і ніхто це все не тестував... День Х наближався, залишалося менш як тиждень до релізу, підключили тестувальника, щоб хоч одним оком глянув, що робиться. Команда працювала всі вихідні й ніч перед релізом, щоб хоч щось адеквате вигрузити замовнику.

Тому, якщо волієте вночі поспати, а не багфіксити — підключайте тестера від початку проекту. Дотримуйтеся правила, що чим раніше знайшли баг, тим дешевше він коштує.

Т&М — не Т&М, якщо ви називаєте якісь суми замовнику

Прилітає сейлз-менеджер і каже, що потрібен раф естімейт проекту й що треба на ранок, бо вже домовилися із замовником? Ти в паніці бігаєш за тімлідами, щоб дали хоч якусь оцінку. «А що треба зробити?», — запитують тебе, а ти не знаєш, але треба на завтра. Якимось магічним чином усе-таки з’являється приблизний скоуп, його оцінюють пальцем у небо, і до кінця дня ти видаєш сейлзу число: 50к баксів. Говориш про все із сейлзом, кажеш, що це дуже приблизно й на це підписуватися не можна. Сейлз каже: та не парся, то ж Т&М.

Не знаю, що ті сейлзи далі роблять, але клієнт підписує контракт і починає з вами працювати. І ви підписалися на Т&М, і це ніби круто. Та є одне маленьке але... Ви назвали якусь суму замовнику, і він її запам’ятав на все життя. І ось ви почали працювати над проектом, унесли мільйон правок, тричі перемалювали дизайн... І в сумі вартість проекту вже не 50к, а 150. Але кого те взагалі гребе, ми ж за Т&М працюємо. А гребе це замовника, якому на початку вже назвали ціну. І його вже не гребе, що ми тричі змінили дизайн, бо ж казали 50к.

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

Один розробник на проекті, і він іде у відпустку

Це, напевне, очевидно, але все ж... Поки це сам не переживеш, не зрозумієш увесь біль такої ситуації.

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

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

Тож треба розібратися, і досить терміново, бо ризикуємо втратити користувачів. Підключаю я до завдання ліда розробників і ліда тестерів, бо бага виявилася ще й плаваючою. Лід розрабів каже, що потрібні доступи до логів і сервака, я біжу до девопса, а його немає на робочому місці, бо робочий день уже закінчився. Вибігаю до вхідних дверей: чувак уже перезувся й у літній легкій курточці, зі своїм чорним босівським пакетом у руках, відчиняє двері і піднімає ногу, щоб переступити поріг. Цієї миті я підбігаю, у паніці намагаюся щось пояснити, моя рєчь в той момент звучала приблизно так: «У нас проблеми, сервак, логи, не работає платьожка, там Іван і Степан, треба доступи...»

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

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

Особливості ринку запуску проекту

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

Ми розробляли застосунок, у якому кількість екранів можна перерахувати на пальцях рук. Стартували з iOS-версії, і особливість була в тому, що запускати продукт планували в Азії й усі від початку це знали (мали б про це знати). За два місяці розробки ми виходили в перше бета-тестування. Застосунок протестували мільйон разів. Ми дуже чьотко вписувалися у співвідношення бюджету й скоупу, за строками навіть випереджали план, й у нас було кілька тижнів у запасі.

І от виходимо в бета-тестування, яке проходило в Китаї, де є особливість з китайфонами й обрізаним iOS SDK. У користувачів застосунок крешиться, тестування йде по одному місцю, замовник злий, менеджер у паніці, розробники в недоумєнії.

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

Почуття гумору

Я взагалі палкий прихильник шуточок і мемасів та вважаю, що без них ніяк. Але почуття гумору — це дуже тонка штука (особливо якщо ваші жарти пласкі). Не всі розуміють жарти, не всі можуть розпізнати сарказм і не всім притаманна самоіронія.

Почитали статтю й посміялися — добре... Але якщо мій роботодавець зрозуміє, чия це стаття, то завтра HR може покликати мене в кабінет і сказати, що я більше не працюю в компанії XYZ. Жарти жартами, але мене трохи не звільнили за мій гострий язик, тому треба знати міру (і в кожного вона своя). Перед тим як жартувати, треба розуміти аудиторію, і чи взагалі люди сприймуть усе правильно.

І насамкінець хочу сказати: не бійтеся ризикувати, використовувати нові методології й технології. Помилки — це нормально. Головне, робити висновки й рухатися далі. Ухвалюйте рішення й несіть за них відповідальність. Не всі рішення будуть правильні, але краще неправильне, ніж узагалі ніяке.

Це моя перша стаття, тому не судіть строго. Дякую тим, хто дочитав до кінця.

Ілюстрації Романа Кривенка

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось5
До обраногоВ обраному15
LinkedIn



49 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.
Працюючи в аутсорсі, постійно треба засунути щось в зжаті ср*ки

когда же наконец дойдет до Лиги защитников интересов клиента, что так оно не работает.

бекендер у паніці намагається відкотитися

в github есть волшебная кнопка Revert для создания обратного PR (если вы работаете с pull request), ее может нажать любой желающий без знания технологии.

Жарти жартами, але мене трохи не звільнили за мій гострий язик

Если сказано по теме, и не вредит бизнесу, например, вы высказали внутри команды, а не клиенту, то лучше найти другую компанию, если в этой не ценят критику и обижаются на правду

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

аж трохи заволав )))

Дякую за такий чудовий огляд. Все дуже життєво.

Отличная статья с юмором и, что самое главное, жизненно))

Та є одне маленьке але... Ви назвали якусь суму замовнику, і він її запам’ятав на все життя. І ось ви почали працювати над проектом, унесли мільйон правок, тричі перемалювали дизайн... І в сумі вартість проекту вже не 50к, а 150. Але кого те взагалі гребе, ми ж за Т&М працюємо. А гребе це замовника, якому на початку вже назвали ціну. І його вже не гребе, що ми тричі змінили дизайн, бо ж казали 50к.

А если аргументировать такой вот фразой: «минимальная по качеству реализация требований будет стоит 50k, максимальная до 50 млн (ну или без оценки)». А дальше и заказчик осведомлен и укладывает хотелки в бюджет и разумные требования.

Люди всегда видят минимальную цифру и расстраиваются если она больше

Так что мешает сделать по минимальной цифре с индусским качеством? Вы же купив китайский телефон за 100$ не жалуетесь что кроме звонилки, месенджеров и интаграмма там ничего другого толково не работает и еще все подглюкивает.

Сейчас то, что за 1000 чаще всего работает, как за 100.

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

Весь инет забит воплями страждущих, что вот взял за 100, а хочу, чтобы работало, как за 1000.

Ну так они и будут страдать и дальше. Самое интересное, что хорошие дорогие китайцы работают в разы лучше многих брендовых.

Профессионализм. Противно говно лепить.

Это после пары коммерческих проектов лечится, так что будешь лепить по оплате. Ну и кроме того зачем говно? Просто можно сэкономить, захадкодить sql в коде, поубирать проверки, пароли в plain text хранить. Но делать качественно. При такой организации заказчик к вам еще не раз вернется латать дыры.

Как вот все эти «бонусы» можно было поймать? Нужно иметь талант. Видимо сертификации всё таки что-то дают. Литературы, статей и видосов все же недостаточно.

Малюнки розкішні :)
а що до оцінки ціни проекту — відомо ж, що хтось у ланцюжку має домножити естімейт на 3. Рівно так ціна і піднялась. (Що не скасовує необхідности закластись на зміну вимог... але обгрунтовано.)

Діте теж люди ) І вони теж хочуть вчитися/працювати/заробляти.

И зачастую давно уже не в найме, а консультанты или владельцы.

Можна так і виступити десь із темою про типові помилки ПМ-а в аутсорсі ;)

Даже цiкаво пишите. Я з захопленням читав кожен роздiл як окреме оповiдання.

Выводы.
1. Если человек идёт в отпуск это проблема, даже в заранее оговоренное, за пол года известное время.
2. Если человек может дать звездюлей это проблема.
3. Работа в оговоренное время и отсутствие бесплатного доступа в не оговоренное — проблема.
4. Не желание овертаймить, тем более бесплатно — проблема.

Автор, твоя контора говно, лютейшая соковыжималка. Меняй её, или поставишь мужчин в неудобное положение — девушку не удобно посылать на хер! А не послать нельзя.

«Флюгегехаммер» это пять. Пошёл искать картинку с молотом.

Яда? Полноте, я с молоточком хожу. Как только мне про бесплатный овертайм я молоточком тюк

Автор же не кичится этим(как в статье от сео генезиса), а является такой же потерпевшей стороной, как и разработчики

Зачем она там сидит? Полно нормальных мест работы

5.

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

— проблема.

И в то же время

не бійтеся ризикувати

Даже добавить нечего))

У складі джуна-фронта, який тиждень тому вперше побачив Vue.js та аутстафера, який раніше писав на Angular, а не на Vue, ми починаємо розробку. [...] чувак виявився норм рівня, дуже відповідальним і вболівав за результат. [...] в нас два розробники на бенчі й треба їх чимось зайняти. [...] настояла, щоб ми принаймні відмовилися від аутстафа за таких розкладів.

тобто кікнули єдиного, на кого можна було покластися?

хто ілюстрації робив? подвійний респект йому/їй

Ілюстрації Романа Кривенка
особливість з китайфонами й обрізаним iOS SDK

В Китае айфоны не такие, как в остальном мире?

Нет флага Гонконга на стандартной iOS клавиатуре?

Капец життя важке в мелких львовских конторах...

Тому, якщо волієте вночі поспати, а не багфіксити — підключайте тестера від початку проекту. Дотримуйтеся правила, що чим раніше знайшли баг, тим дешевше він коштує.

Ох, помню как ты тоже мне это говорил, спрашивая :" А для чего нужен тести’р’овщик " а я говорил, что для того, чтобы превентировать появления багов в продукте ... И казалось бы правильный ответ, только нихуя он неверный и нихуя я не понимал для чего вообще нужен тестер. Я так прочитал где-то и говорил это как попугай — неосознанно. Вы, правда, меня все равно кикнули тогда, а я сразу со своими знаниями без курсов попал в это самое айти, да так натестировался, что уже пишу софтину, а ты ведь тогда у меня и спрашивал:" че, пишешь софтину, п’р’икосалася руками к ’р’аз’р’аботке" а я нихуя вообще не знал тогда. Как сейчас помню, Винница, весна, 2018 год. А я хочу вайти в ойти. Собеседования.И я иду с ощущением, что я ебал вообще такие интервью:
— ’Почему этот картавый молдован так деркзо себя ведет и че это он не хочет пустить меня к халявным деньгам". Осознал я все сквозь время. Халявных денег нет, правильно сделали, что не пустили, а для чего нужен этот самый тестер я понял только уже на позиции девелопера.

Только сейчас, спустя спустя все это время. ..осознал.

Мистер Кэнди, что это молдавский нигер себе позволяет!? ©

Працюючи в аутсорсі, постійно треба засунути щось в зжаті ср*ки.

Это гениально)

Крута стаття! Чекаю ще:)

Ох як багато з цього знайомо))

Классная статья, и посмеялся, и поплакал. Иллюстрации супер

Классная иллюстрация :)

Підписатись на коментарі