Як зрозуміти, чи приніс розробник цінність для бізнесу

Привіт усім, я — Олександр Короп, Senior Software Engineer в компанії AMC Bridge. Я працюю в ІТ 8 років і моя основна спеціалізація — розробка 3D-графіки у вебі за допомогою JavaScript. Звісно, за свою роботу я бачив багато прикладів успішних та неуспішних проєктів. Тому сьогодні хочу поділитись своїм баченням того, як програмісту робити більше успішних проєктів. А саме — чому розробникам вкрай важливо розуміти не лише технології, але й бізнес-завдання замовника.

Здавалось би, чому я хочу поговорити на бізнесову тему? Як це дотично до моєї роботи? Відповідь проста: розуміння цінності для бізнесу (business value) — це той інструмент, який допомагає мені побачити технічні завдання під новим кутом та краще розуміти, яку саме роботу потрібно виконати. Багато хто вважає це надлишковим. Але це те надлишкове, що за певних обставин переходить у ранг гострої необхідності та впливає на ваш персональний успіх.

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

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

Сумні подробиці невдач

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

Випадок перший. Замовник курував процесом розробки, виконував роль product owner та частково product manager. Він брав участь у наших щоденних стендапах, формуванні тікетів, пленінгах, ретро-мітингах тощо. Словом, тримав руку на пульсі. Але попри це виникали ситуації, коли ми виконали всі узгоджені із ним завдання, а він — розчарований. «Я очікував, що реалізація цих завдань дасть змогу користувачам робити це, це і це. Але цього немає», — казав він. Уявіть наше здивування, коли ми йшли чітко за вимогами та дотримувались плану, а замовник не задоволений. Ми опинились в ситуації, коли реалізація не відповідала очікуванням замовника. І я бачив такі ситуації не один раз, особливо, на фрілансі.

Були й менш тривіальні випадки. Ми працювали над перенесенням десктопного застосунку у хмару. Одна з його головних складових — крута фіча, яка дуже важко реалізовувалась, і якою особливо пишалась команда розробників. Нам потрібно було зрозуміти, як із нею працювати, тому ми довго спілкувались із командою клієнта щодо того, як вони її реалізували. І вже на якомусь з етапів, коли почали спілкуватись із product-менеджером, він повідомив, що цієї основної фічі у хмарі не буде. «Наші кінцеві користувачі у десктопі нею не користуються», — повідомив він. Тут два в одному: перше — круто реалізована робота виявилась не потрібною користувачам, друге — зворотній зв’язок про це дійшов до розробників лише за пів року. Я не перебільшу, якщо скажу, що мітинг, на якому це з’ясувалось, був дуже яскравим.

Третій випадок узагальнюючий. Уявіть, що команда працює над додаванням нового функціоналу. Все сплановано, є документація, а вимоги чіткі та зрозумілі. Але раптом з’ясовується, що потрібно доробити ще кілька блоків або отримати зворотній зв’язок від замовника, щоб закінчити роботу. Реакція замовника: «Це не входило у плани», — тому це фінальне доопрацювання летить у дальній ящик — можливо, колись доробимо. Що відбувається у цій ситуації? Через те, що відмовились докласти маленькі зусилля (просто, бо вони не були заплановані спочатку), ціла фіча не потрапила у продукт. Результат такий же: користувач не отримує можливість робити щось нове або робити щось швидше, а замовник не отримує додаткової цінності, яку він би міг монетизувати.

Це не наші провтики!

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

«Це не наші провтики! Чому ми маємо про це думати, ми ж — інженери», — скаже хтось із вас. Але, на моє переконання, робота програмістів має безпосередній ефект на продукт та бізнес. І нехай це складно побачити у великому ентерпрайз-проєкті, але, повірте, це легко розпізнати у невеличкому стартапі. Про такий проєкт, в якому я зараз працюю з боку AMC Bridge, я розповім нижче.

Приклад вдалої реалізації цінності для бізнесу

Це health care продукт, який дає можливість індивідуального протезування в галузі ортодонтії. Клініка робить 3D-скан щелепи пацієнта, фахівці його опрацьовують, лікарі затверджують результат, а hardware команда генерує модель протезу та друкує її. Пацієнт же з мінімальними зусиллями та в межах однієї компанії отримує протези, зроблені з його скану, які легко встановити. Як ви зрозуміли, ця компанія має повний цикл — від сканування до виробництва. Тому дуже легко відстежити, як рішення конкретних розробників впливають на результат.

Які цілі стояли перед бізнесом

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

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

Цілі, які поставив замовник

  • Перехід від десктоп-застосунків до використання CAD у хмарних сервісах.
  • Інтеграція 3D-скануючих пристроїв в одну систему завдяки IoT і контролю через вебзастосунки.
  • Використання WebGL для створення більш зручного, точного інтерактивного юзер-інтерфейсу для техніків компанії та лікарів, які перевіряють результати роботи.
  • Інтеграція кількох вебзастосунків в один, щоб уніфікуфати робочий процес.
  • Маніпуляції, щоб зробити деплоймент без простоїв.

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

Я — програміст! Для чого мені це все?

Якщо ви — розробник, вам може здатись, що це все занадто далеко, адже пов’язано не з програмуванням, а з бізнесом. І цим мали би перейматись продуктові менеджери, проєктні менеджери, бізнес-аналітики та всі інші.

«Дайте тікети, пропишіть вимоги, методологію, поменше мітингів — і я дам вам хороший результат», — скажете ви. І це все частково має сенс. Якщо в команді є всі ці ролі, то інженеру, можливо, і не так важливо про таке задумуватись. Втім, якщо в проєкті немає великої команди, то часто виникають труднощі. І тут ми виступаємо не так в ролі інженера, як розробника. Коли замовник озвучує проблему та ідею, а ми використовуємо свої технічні знання, щоб допомогти йому покращити продукт.

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

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

Типи цінностей для бізнесу

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

Комерційна цінність — це те, що можна продати. Наприклад:

  • нова версія пакету ПЗ, за доступ до якої користувач повинен внести додаткову оплату;
  • нові варіанти підписки, які приводять більше користувачів, тому що тепер можна обирати більш доступну для себе підписку;
  • зниження кількості операційних витрат;
  • можливість формувати індивідуальний рахунок за конкретно використані послуги (як це робить Amazon).

Як перевірити, чи ця цінність додана? Поставте питання на перевірку: який прибуток отримає замовник, додавши до продукту певний функціонал?

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

Питання на перевірку: скільки нових користувачів користуватиметься продуктом?

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

Питання на перевірку: скільки часу та грошей зекономить впровадження нового або покращення старого функціоналу?

Цінність для споживача — рішення, яке утримує існуючих користувачів.

Питання на перевірку: яка ймовірність, що клієнти залишаться з нами, якщо ми запровадимо ці зміни? І навпаки: яка ймовірність, що вони підуть, якщо ми цього не зробимо?

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

Питання на перевірку: скільки грошей ми зекономимо в майбутньому?

Дбати про цінність для бізнесу ≠ поганий код

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

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

Як цінність співставляється з важливими поняттями та принципами розробки

  1. Цінність для бізнесу є і в гнучких (Agile), і у негнучких (Waterfall) методологіях розробки.
  2. Якщо говорити про acceptance criteria, то вони не тільки не відкидають цінності, а й можуть її кодифікувати або формалізувати. Тобто, ви в acceptance критеріях можете побачити конкретні пункти, які допоможуть додати business value.
  3. Цінність є і у функціональних, і в нефункціональних вимогах. Просто тікети, сторі, епіки — це деталі розробки. А бізнес-цінність — можливість побачити картину в цілому. Щоб раптом не опинитись за її межами, реалізуючи те, що користувачу не потрібно.

Що може піти не так?

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

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

Другий ризик — ймовірність потонути у meeting culture. Коли мітинги відбуваються заради мітингів, а люди подовгу слухають інформацію, яку вони не розуміють. Більше мітингів — менше часу на кодинг. Ми мало деліверимо? Тоді давайте поговоримо про це!

Третя проблема, яка може виникнути — коли у стейкхолдерів немає спільного бачення бізнес-вел’ю. Тоді кожен із них наполягає на своєму, а розробник не знає, яке головне завдання у його роботи.

І наостанок — цінність для бізнесу це така річ, яка може змінюватись. Її актуальність потрібно обговорювати, а це знову повертає нас до meeting culture.

Що робити

Отже, що робити розробнику, щоб надавати бізнесу не просто код, а рішення та цінність?

  1. Не починати писати код, допоки не переконались, що правильно зрозуміли завдання. Пригадуєте те тепле відчуття у грудях, коли бачите завдання, рішення якого ви вже знаєте? І як потім, сидячи по вуха в коді, усвідомлюєш, що не поставив потрібну кількість запитань, не знаєш кінцевої цілі, або знаходиш схожий реалізований функціонал, який можна було використати для того ж завдання.
  2. Ставити багато запитань людям, які ставлять завдання. Маючи концепцію цінності для бізнесу, ми можемо ставити питання не з позиції «що мені потрібно зробити», а «яке рішення має бути для користувача». Так може з’ясуватись, що завдання, з яким замовник прийшов до вас, вимагають змін, а скоуп може як збільшитись, так і зменшитись.
  3. Продумати максимальну кількість тест-кейсів, але тих, що покриватимуть бізнес-цінність, а не просто код.
  4. Прописати код текстуально, перш ніж ви захопитесь його оптимізацією.
  5. Лише тепер переходити до реалізації.

Як оцінити, чи рішення надано

Цю відповідь можна знайти, відповівши на питання для контролю з розділу «Типи цінностей для бізнесу». Але можна піти коротшим шляхом: як думаєте, чи може кінцевий користувач скористатись продуктом та сказати «Дякую, допомогли!»? Якщо відповідь «Так» — вітаю! Ви виконали свою роботу блискуче! Якщо відповідь «Ні» — то нічого більше не має значення. Робота не завершена і її не можна випускати користувачеві.

And the winners are...

Наостанок давайте розберемось, хто потрапляє у список переможців від такого нашого підходу?

Користувач — він отримує те, що працює швидше, краще, зрозуміліше або робить те, чого раніше не робило.

Замовник — може легше продавати свій крутий продукт та збільшити прибуток. Він отримує не просто відповідь на своє запитання, а проактивну команду, яка може запропонувати новітні рішення, про які він навіть не знав.

Компанія-підрядник. Замовники залюбки продовжують співпрацю з підрядниками, які допомагають їм збільшувати прибуток.

Команда компанії-підрядника, яка зменшує шанси на помилку. Розуміння цінності для бізнесу перетворить вашу роботу з написання коду у надання цінності, і ви як команда будете почуватись круто. Бо що ще треба розробнику окрім того як бачити, що його «дітище» працює і дає користь.

Розробник. Коли програміст знає бізнес-складову питання, говорить із замовником однією мовою (на додачу до технічної експертизи та знання трендів), це збільшує його цінність в очах замовника та підвищує вартість на ринку. Коли на співбесідах вас просять розповісти з чим ви працювали, і ви кажете про сервіси, компоненти, бази, інтерфейси тощо — це ок. Коли ви говорите про додану цінність, яку ваша робота принесла реальному бізнесу — ваш рівень в очах інтерв’юера різко підвищується.

Як людина, яка проводить співбесіди, я таке дуже ціную. І знаю, що інші також.

Підсумок

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

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

Публікації, які свого часу допомогли мені зорієнтуватись в цій темі: ‘What Is This Thing Called "Value"?’ (Medium), "Как попасть в Google: инструкция по подготовке (DOU).

👍НравитсяПонравилось7
В избранноеВ избранном1
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Если заказчик не жалуется — значит все нормально)
Народная мудрость аутсорса)

давайте вже статті на тему: Як зрозуміти чи приносить компанія користь своїм робітникам?)))) А те, що ви написали в принципі очевидно.

Ценность мы будем приносить , когда на то , что мы пилим , получим долю, а пока от забора до обеда пилить за зепку на 2х-3х таких же уникальных конторах.

Перед вами — успішний приклад, коли рішення, яке надала команда, створило цінність для бізнесу.

Але навіщо було для виконання наведених цілей від замовника потрібно якось саме розуміти бізнес вимоги, а не лише технології?

Ну і ви пишете про персональний успіх, але із 8 роками досвіду у фронтенді сидете у AMC Bridge, де 5к навіть не дають, наскільки мені відомо. Може ну його, дрочити ангуляр та валити?

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

Поки не видають стоки — нафіг якась цінність

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