Бізнес vs розробка. Як ефективна комунікація з бізнесом підвищує якість розробки ПЗ

Привіт! Мене звати Владислав Зубков і вже понад 5 років я займаюсь розробкою iOS і macOS програм в команді Nektony.

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

Коли легасі наздогнало в найневдаліший момент

Наведу приклад з продуктом, що розроблявся з самого старту компанії (2011 рік). Що набагато довше, ніж працює в компанії будь-хто з теперішньої інженерної команди.

На той час продукт запускався за принципом MVP, але згодом у такому вигляді й продовжив розвиватися та обростати додатковими фічами.

Команда нових розробників застала його в стані макаронного коду, що значно розрісся. Тобто коли присутня велика зв’язність, божественні класи й до того ж весь інтерфейс реалізований через єдиний xib-файл. І навіть ми ще протягом деякого часу, коли з’являлися задачі по цьому застосунку, весь процес організовували суто під запит бізнесу «швидко оновити або додати щось», не намагаючись покращувати код.

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

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

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

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

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

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

Позитивний приклад запуску нового продукту

Кілька років тому перед нами постало завдання зробити нову програму для Mac App Store за кілька тижнів.

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

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

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

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

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

Наведу з власного досвіду приклад того, як екстравитрати на початку окупають себе згодом. Компанія Nektony розробляє понад 10 продуктів. У кожному застосунку є діалоги About, Preferences, News, Alerts тощо. Вони завжди виглядали у всіх продуктах майже однаково, з відмінністю тільки в колірній гамі. Але в кожному застосунку ці діалоги були реалізовані окремо. Таким чином, якщо десь була виявлена ​​якась бага — треба було не забути додати фікс у кожен продукт. А потім ретельно протестити. В окремих продуктах діалоги могли почати чимось відрізнятися і жити своїм життям без явної потреби, просто тому, що у команди дизайну в цей день було натхнення 🙂.

В результаті при додаванні правок в кожен продукт та намагань досягти pixel perfect результату, все починало забирати більше часу.

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

Ми порахували та показали у цифрах і за конкретними тасками, скільки це займає у розрізі року (як в розробці, так і в тестуванні). Наприклад:

• Повністю оновити діалог під новий дизайн — від 1 до 3 годин часу програміста на один продукт залежно від дизайну.
• Незначні зміни (форматування напису, колір тексту, колір кнопки, додавання hover-ефекту тощо) — від 10 хвилин до 1 години на один продукт.
• Продуктів всього 10, тому кожну задачу множимо відповідно на 10. І виходить, що замість 1-3 годин ми витрачали 10-30 годин на оновлення одного діалогу. Якщо помножити ці показники ще на 5 оновлень в рік та додати час на тестування і перевірки, виходила відповідно велика сума витраченого часу.

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

Було

Стало

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

Як творчий порив одного програміста зекономив багато грошей бізнесу

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

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

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

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

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

Тому мій колега Володимир Нуждін суто на власному ентузіазмі зайнявся цим завданням. Він написав скрипт, що експортує з Figma всі стилі та генерує на Swift-компоненти для використання цих стилів. За посиланням можна знайти інструкцію з написання скрипта для Figma.

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

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

Підсумок

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

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