Розробка інкременту

Розробка вимог

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

Передусім ми створюємо попередню конструкцію рішення і доказуємо малоймовірність технічних загроз задачі. Кожний інкремент має вписуватися у продуктові обмеження чи обґрунтовано змінювати їх, інакше можна очікувати проблеми в будь-якій іншій частині продукту. Якщо недооцінити технічні загрози задачі, то увесь код, написаний для її вирішення, прийдеться викидати, коли з'ясується, що якусь частину задачі реалізувати взагалі неможливо. Ми зберегли нашим клієнтам немало грошей тільки тим, що перевіряли API 3rd-party продуктів до інтеграції з ними. Кілька тестових запитів до цих API через Postman – і ми вже знаємо, що очікування розходяться з реальністю , а вимоги треба вибудовувати по-іншому.

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

Особливу увагу ми приділяємо проєктуванню технічної частини. На цьому етапі від постановника задачі потрібно отримати максимум технічного контексту для того, щоби ми могли врахувати усі фактори і безпечно вписати інкремент в продукт. Точно сформульовані вимоги дозволяють не тільки мінімізувати загрози, але й скорочують час розробки. Ми часто пишемо припущення зміни схеми даних, ідеї щодо кращих абстракцій, і загалом будь-які думки щодо оптимізації процесу розробки. Для якісного результату роботи програмісту потрібна свобода у прийнятті рішень, у той час коли продукт вже захищений чіткими acceptance criteria. Загалом ми швидше підказуємо розробнику шлях до побудови правильного рішення, ніж жорстко диктуємо його.

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

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

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

Програмування

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

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

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

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

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

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

Успіх наших продуктів ґрунтується на майстерності наших програмістів.

Розробка інтерфейсів користувача

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

Для розв'язання задач у сфері дизайну ми часто залучаємо інших спеціалістів коли нам потрібен вищий рівень експертності. У будь-якому випадку, відповідальність за підсумковий результат лежить цілком на нас. Щоби надати кінцевому споживачу дійсно якісні рішення ми максимально фокусуємось на з'ясуванні ключових аспектів користувацького досвіду. Якщо мова про B2C-продукти, головний орієнтир – це комфорт і зручності користувачів. Для B2B-продуктів важливіше зробити інтерфейси ефективними інструментами для вирішення проблем користувача, навіть в нетипових ситуаціях.

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

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