Дякую! 🫶🏻

Дуже дякую за відгук! :)

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

2. Спитайте прямо про овертайми, робочі години та години, коли вам треба бути на звʼязку. Це перше і очевидне. З неочевидного: уточніть про процес аналізу вимог та планування та наскільки він гнучкий, бо овертайми часто витікають з помилок на ранніх етапах розробки, коли забули уточнити, описати і спланувати. Чим більше від вас очікують здогадуватись і читати між рядків, тим більший ризик, що ви це будете робити в позаробочий час.

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

Не можу прив’язати LinkedIn, підтвердіть, будь ласка, акаунт.