Уявіть собі, що ви працюєте над важливим проєктом, де потрібно впровадити нову функцію — наприклад, динамічну користувацьку панель з оновленнями в реальному часі. Розробник впевнено заявляє: «Я вже ознайомився з вимогами. Це має бути нескладно, на все піде день-два». Здається, все йде чудово, поки не приходить день, коли функція мала б бути готова, а замість цього ви чуєте: «Виявилося, що є проблеми з API, і потрібні зміни в архітектурі коду».
Тепер проєкт затримується на цілий тиждень, а ви починаєте сумніватися, чи дійсно розробник розумів усю складність завдання з самого початку або просто не подумав і тепер ви «вихоплюєте на горіхи» від клієнта..
Такі ситуації часто виникають, коли заздалегідь не ставляться правильні запитання. Справа не в тому, що розробник бреше чи відноситься до проєкта неуважно. Просто кожен з нас занурений у свої контексти і тому бачить світ з певного кута. Щоб ви навчились перекладати з розробницького на зрозумілий і відстежувати потенційно проблемні ситуації ми підготували 4 історії в яких стався факап і список запитань, які могли б цього не допустити.
Як впровадження нової функції може перетворитись з легкої задачі в проблему
Що каже розробник
«Я ознайомився з вимогами для нової функції користувацької панелі, яка включає динамічний інтерфейс з оновленнями в реальному часі, використовуючи React та Redux. Згідно з моїм досвідом, це має бути доволі просто. Обробка даних через REST API здається керованою, і я добре знайомий з потрібними паттернами управління станом. Думаю, що впровадження займе один-два дні, якщо не виникне неочікуваних проблем з API або серіалізацією даних».
Факап
Пізніше розробник стикається з проблемами сумісності та продуктивності, що затягує процес на тиждень. Замовник починає сумніватися, чи розробник справді врахував усі можливі складнощі.
Як можна було цьому запобігти
Список запитань, які допомагають уникнути таких факапів:
- Які конкретно кроки ти плануєш виконати для впровадження цієї функції? З якими складнощами ми можемо зіткнутися на кожному кроці?
- Чи ти перевірив документацію API і сумісність з нашим поточним стеком технологій? Які нюанси слід врахувати?
- Чи плануєш тестування після інтеграції?
Що буде, якщо поєднати «їжа з вужем»
Що каже розробник
«Я зробив попередню перевірку нашої інфраструктури в AWS, включаючи існуючі EC2, конфігурації VPC і групи безпеки, і впевнений, що ми можемо інтегрувати новий платіжний шлюз без значних змін. Наш бекенд на Node.js повинен підтримувати необхідні API виклики. Можливо, доведеться трохи налаштувати IAM ролі, але серйозних проблем не передбачаю. Загалом, це має бути гладка інтеграція».
Факап
Після початку інтеграції виявляється, що шлюз використовує інші протоколи, що потребують додаткових ресурсів і залежностей. Замовник починає сумніватися, чи розробник справді перевірив всі вимоги сумісності.
Як можна було цьому запобігти
Ще в першій розмові з розробником варто задати декілька запитань:
- Чи ти проводив повну перевірку сумісності інфраструктури клієнта з новим платіжним шлюзом? Які саме перевірки ти робив?
- Чи міг би ти детальніше пояснити, які оновлення або зміни можуть бути необхідні у інфраструктурі клієнта?
- Чи є у тебе досвід інтеграції подібних сервісів?
А щоб вирішити проблему непорозуміння і стати «своїм» для розробників, приходьте на курс Techmind. Прокачайте технічну експертизу, щоб робити реалістичні оцінки термінів та вартості, а також деліверити проєкти за будь-яких умов.
За 2 місяці ви оволодієте термінологією SDLC, техніками роботи з Jira, навичками написання проєктної документації, та навчитеся спілкуватися з програмістами однією мовою.
Не тільки на розробці можна збанкрутіти
Що каже розробник
«Я перевірив кілька варіантів для відправки повідомлень користувачам, включно з Twilio для SMS і Firebase для push-нотифікацій. Здається, Twilio підходить, оскільки підтримується широко, і, наскільки я зрозумів, вартість незначна на нашому рівні використання. Пропоную почати з SMS, а якщо буде потреба, згодом можемо переключитися на push-нотифікації».
Факап
Через тиждень клієнт отримує значний рахунок через більший обсяг використання SMS. Замовник відчуває, що розробник міг не до кінця вивчити цінову політику.
Як можна було цьому запобігти
Насправді, для уникнення такої ситуації достатньо всього одного-двух запитань:
- А можна розрахунок вартості кожного з запропонованих сервісів з урахуванням очікуваних обсягів використання? Чи враховане використання для всіх регіонів?
- А безкоштовні рішення є?
Все чітко і зрозуміло, поки не починаєш працювати
Що каже розробник
«Я переглянув документацію API від постачальника, і на перший погляд вона здається досить стандартною. Виглядає так, що ми зможемо мапити більшість об’єктів відповіді до наших існуючих моделей даних. Вважаю, що інтеграція має бути завершена до кінця тижня, якщо API працюватиме, як очікується».
Факап
Під час інтеграції виникають численні проблеми, такі як ліміти швидкості і неочікувані формати відповідей. Замовник починає сумніватися, чи розробник дійсно уважно прочитав документацію.
Як можна було цьому запобігти
Тут взагалі все просто – перед тим як перейти до роботи не лінуйтесь і задайте розробнику декілька питань по документації. Наприклад: «Чи є в документації обмеження, які можуть вплинути на нашу інтеграцію?ї» Якщо документація не була вивчена, ви відразу це побачите.
Спілкування з розробниками може бути непростим, особливо якщо ви не знаєте, які питання ставити і як забезпечити прозорість у роботі. Але пам’ятайте, що ефективна співпраця будується на взаємній довірі, чіткості та деталях. Не треба думати, що всі навколо брешуть, помʼятати, найчастіше за все кожна людина хоче виконати свою роботу добре. Проблема в тому, що всі ми – люди і тому задача менеджера – передбачати ситуації, коли неуважність призводить до справжніх проблем. Щоб робити це ефективно – вчіться розмовляти з розробником однією мовою.