Як це — бути розробником в Depositphotos, HYS Enterprise, BeLight Software і Serpstat

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

У цьому випуску — розповіді розробників з київського офісу Depositphotos та одеських HYS Enterprise, BeLight Software і Serpstat.

Depositphotos

— Розкажіть про вашу команду і про те, над чим ви працюєте?

Відділ розробки складається з декількох скрам-команд. В нашій команді 11 людей — це і розробники, і QA. Команди автономні і можуть самостійно вирішувати завдання в рамках свого проекту.

Основне завдання нашої команди — розробка сайту Depositphotos. Ми робимо і інтерфейсну частину, і те, що «під капотом». Реалізуємо рішення для корпоративних і бізнес-клієнтів, а також запускаємо нові фічі для звичайних клієнтів — покупців і авторів.

— Які інструменти розробки використовують у вашій компанії?

Для розробки ми використовуємо досить звичайний для 2018-го року «джентльменський набір». Це Git, Jira, Fisheye, Confluence, Jenkins (CI), Slack і Skype. Для забезпечення розробки ми вирішили не використовувати весь Atlassian stack, тому що Jenkins виявився більш гнучкий, ніж Bamboo.

— На яких мовах програмування пишуть розробники?

Залежить від задач. В основному це JavaScript, PHP і Java.

— Як виглядає процес розробки, життєвий цикл продукту?

Процес розробки у нас проходить по Scrum: функціонал доставляється ітеративно, протягом спринтів. Це дозволяє замовнику реагувати на зміни і вносити коригування в розробку. Звичайні етапи — це планування, розробка, код рев’ю, тестування, переклади (якщо потрібно) і деплой.

— Як прийнято проводити код рев’ю?

Код рев’ю — обов’язковий етап в процесі розробки: код не може бути змержен без рев’ю. Будь-які дефекти коду, знайдені на рев’ю, повинні бути виправлені.

Код рев’ю ми проводимо в Fisheye. Самі рев’ю створюються автоматично після того, як задача готова. Рев’ю розділені по ролям, що дуже зручно. Наприклад, програміст на JavaScript не буде перевіряти код на Java. Якщо, звичайно, сам не захоче :)

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

— Як прийнято проводити тестування, які тести застосовуєте?

У нас є кілька видів автоматичних тестів, які запускаються після того, як задача виконана. Це перевірка стилю коду, юніт-, API- і UI-тести. Ми намагаємося покривати автотестами весь новий функціонал. І обов’язково покриваємо автотестами багфікси: якщо щось зламалося, потрібно бути впевненим, що в наступний раз це не зламається знову.

При розробці задачі, якщо всі автоматичні тести пройдено, до тестування підключаються QA. Їх завдання — перевірити роботу з точки зору користувача і прогнати «хитрі кейси». Часто вони рятують команду і знаходять проблеми, не дозволяючи багам потрапляти в продакшн :)

— Як відбувається розгортання (деплой)?

Ми практикуємо CD, тому деплой проходить кілька разів на тиждень невеликими «порціями». Але для сайту він напівавтоматичний. Є скрипти, які запускаються в продакшн-оточенні. Вони здійснюють збірку проекту і перемикають веб-сервер на нову збірку. Команда розробки не впливає на сам процес деплоя.

— Як проходить типовий робочий день розробника вашої команди?

Ранок починається з розбору повідомлень у пошті і Slack/Skype. Потім у нас проходить daily, на якому команда ділиться своїм прогресом і планами роботи. Далі розробка, тестування, спілкування в месенджерах — і не тільки. Хтось розбавляє роботу грою в теніс або настільний футбол, хтось — перекурами :)

— Скільки годин на день працюєте?

Звичайний робочий день — це 8 годин. З них близько 5-6 годин йде на написання коду. Решту часу з’їдають розмови і обговорення :)

— Хто в вашому випадку є замовником, як влаштована комунікація?

Замовники у нас внутрішні. Наприклад, якщо потрібно провести A/B split з продажів, замовником може бути хтось із відділу маркетингу. Якщо потрібно сформувати звіт — то хтось із бухгалтерії. Спілкування завжди відбувається безпосередньо із замовником.

HYS Enterprise

— Розкажіть про вашу команду і про те, над чим ви працюєте?

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

Команда включає в себе три групи розробників, загалом 15 людей, одну QA команду, з яких 4 manual та 2 автоматизатори, а також 2 бізнес-аналітика та один UI/UX дизайнер.

— Які інструменти розробки використовують у вашій компанії?

Для розробки ми використовуємо MS Visual Studio, MS Management Studio, MS Visual Studio Code, Git. Для тестування — Soap UI, TestRail, SpecFlow. Для білда та деплоймента — TeamCity та Octopus.

Комунікація між компонентами нашої системи відбувається через Virtual Bus, який у свою чергу використовує всередині себе Soap для синхронних викликів і черги для обміну повідомленнями (MSMQ, RabbitMQ) для асинхронних викликів.

Для управління проектом і планування використовуємо Jira та EpicFlow, для комунікацій — Slack, Skype, Gmail.

— На яких мовах програмування пишуть розробники?

Для конекторів до зовнішніх систем ми використовуємо С#. Щодо опису бізнес-логіки, користуємось власною мовою Bella. Для Front-end — Angular 5.

— Як виглядає процес розробки, життєвий цикл продукту?

Розробка проекту розбита на фази, а фази — на спринти. Будь-яка фіча в системі починається зі story в Jira, описаної PO з боку замовника і доведеної до стану Ready For Refinement. Наступний крок — робота бізнес-аналітиків. Вони задають уточнювальні питання PO та вносять правки в story.

Після цього відбувається scrum poker, в результаті якого у story з’являються естімейти і вони переходять до статусу Ready To Start. Далi — планування спринта, на якому PO спільно з тімлідами визначають обсяг наступного спринта. В ході спринта відбувається розробка, тестування і баг-фіксинг згідно з пріоритезованим списком багів.

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

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

На завершальній стадії: end-to-end тестування, dry run тестування, тести продуктивності. Логічним підсумком фази є деплоймент на продакшн-сервери.

— Як прийнято проводити код рев’ю?

Після розробки фічі або виправлення бага розробник робить мердж-реквест в гілку master. Право мерджити в master мають тільки тімліди, які і проводять код рев’ю.

Для мерджа гілки в master досить тільки підтвердження тімліда.

— Як прийнято проводити тестування, які тести застосовуєте?

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

Також, як я вже казав, на завершальній стадії фази проводиться end-to-end тестування, dry run тестування, тести продуктивності.

— Як відбувається розгортання (деплой)?

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

На наші тестові сервери ми можемо робити до 5 деплоїв на день. На сервери замовника зазвичай ми деплоїмо раз на два тижні. Однак на фінальному етапі фази в процесі багфіксінгу на сервери замовника ми деплоїмо кожен день.

— Як проходить типовий робочий день розробника вашої команди?

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

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

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

— Скільки годин на день працюєте?

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

— Як влаштована комунікація із замовником — безпосередньо або через менеджерів?

Ключові питання із замовником вирішують тімліди та бізнес-аналітики. Проте, щоб уникнути ситуації, коли тімлід є bottleneck, із багатьох питань призначаються відповідальні з команд розробників або QA, які також спілкуються із замовником. Демо по кожній story проводить розробник, виконавець story, який і захищає свою роботу перед замовником. Таким чином, можна говорити про те, що із замовником спілкуються безпосередньо всі члени команди.

BeLight Software

— Розкажіть про вашу команду і про те, над чим ви працюєте?

У нашій компанії близько 30 людей, які формують декілька команд за продуктами. У нас є проекти в різних сферах: виготовлення друкованої продукції (Swift Publisher, Printworks), графічний дизайн (Art Text, Letters), інтер’єрний дизайн (Live Home 3D — саме в цій команді я є Project-менеджером), створення резервних копій файлів та систем (Get Backup Pro).

У нашій команді працює 7 спеціалістів: 5 розробників, менеджер продукту та 3D-дизайнер. А тестувальники — це окрема команда, яка тестує всі продукти компанії.

— Які інструменти розробки використовують у вашій компанії?

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

Основна робота програмістів проходить у додатку, який є інтегрованим середовищем розробки (IDE). Оскільки ми розробляємо крос-платформні додатки, ми використовуємо одразу два таких додатка: XCode на macOS та MS Visual Studio на Windows 10.

Третім важливим компонентом є система планування завдань та відстеження помилок. Тут ми користуємося відомим web-сервісом Jira.

Четвертим інструментом є сервіс зручної комунікації, ми користуємось чатом Slack. Ці чотири компоненти — основа, але є ще багато інших допоміжних додатків, які наші розробники так чи інакше використовують повсякденно: TextEdit та Preview на Mac, MSPaint та FarManager на Windows та багато інших.

— На яких мовах програмування пишуть розробники?

Усі наші проекти спроектовано із думкою про можливість портування на інші платформи за потреби, тому проекти складаються із двох основних складових: Core та UI.

Core ми кодуємо на C++. UI на Mac та iOS пишемо на Objective-C, UI на Windows — на C++/CX, це трохи модифікований C++ для написання WinRT додатків. На сьогодні це все, якщо не рахувати PHP, яким користується наш веб-програміст.

— Як виглядає процес розробки, життєвий цикл продукту?

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

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

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

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

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

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

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

Коли майже все готове, продукт набуває статусу beta, інколи ми запускаємо публічне бета-тестування. Наприклад, так було нещодавно з Live Home 3D для iOS. За два з половиною місяці до релізу ми випустили TestFlight версію та залучили понад 1000 сторонніх тестувальників. У цей час команда працює над виправленням знайдених проблем, і нові білди публікуються для подальшого тестування.

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

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

— Як прийнято проводити код рев’ю?

Наші команди доволі невеликі, тому кожен програміст трохи розуміється на майже всіх аспектах проекту. Завдяки цьому, кожен може перевіряти коміти інших учасників проекту, але це не обов’язково. Обов’язково цим займатись лише старшому програмісту (тімліду або менеджеру проекту) або програмісту, відповідальному за архітектуру проекту.

Якщо щось виявляють, то виправляють не мовчки, а обговорюють із автором, якій потім і править свій код. Бувають винятки під час «пожежі», коли немає часу на розмови, бо «горить» дедлайн.

— Як прийнято проводити тестування, які тести застосовуєте?

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

— Як відбувається розгортання (деплой)?

Ми робимо додатки для кінцевих споживачів, тому деплоя як такого немає. Додатки потрапляють на комп’ютери та гаджети наших користувачів найпростішим на сьогодні шляхом — через системний магазин додатків. Це Mac App Store та App Store на macOS та iOS відповідно, Microsoft Store на Windows.

— Як проходить типовий робочий день розробника вашої команди?

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

Зазвичай, основна робота програміста — писати код, але часто треба допомогти колезі. Тут виникають моменти XP програмування. Іноді трапляються обговорення чогось у проекті, і це може затягнутись на кілька годин, але це теж частина роботи розробника.

— Скільки годин на день працюєте?

У нас доволі вільний графік роботи з 10:00 до 19:00 плюс-мінус година. Раніше прийшов — раніше пішов, пізніше прийшов — прибиральниця миє тобі ноги шваброю. Хоча, якщо бути точнішим, програмісти намагаються «дописувати до крапки» — краще сьогодні зупинитись на чомусь логічно завершеному, тоді завтра швидше можна буде продовжувати. Узагалі-то гарний програміст постійно пише код, хоч би й подумки, коли вечеряє вдома чи дивиться новини по телевізору.

— Хто у вашому випадку є замовником, як влаштована комунікація?

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

Serpstat

— Розкажіть про вашу команду і про те, над чим ви працюєте?

У нас один продукт — Serpstat. Ми покращуємо ті сервіси, які в нас вже існують, та розробляємо нові інструменти. Останнім вийшов «Перелік завдань» — інструмент, який дозволяє SEO-спеціалістам розуміти, що їм потрібно робити з їхнім проектом. Також ми постійно покращуємо алгоритми парсингу пошукової видачі.

Зараз у нас близько 30 людей у команді розробки. Це Back-end та Front-end розробники, тестувальники, математики-аналітики, дизайнери.

Коли почалося бурхливе зростання продукту, до нас долучилося понад 15 розробників, і ми розділили усю команду на 7 мікрокоманд. Кожна команда відповідальна за окремий набір інструментів або модулей продукту:

• пошукової аналітики та переліку завдань;
• моніторингу позицій, кластеризації та текстової аналiтики;
• демони пробивки та парсингу пошукової видачі;
• аудиту сайту;
• аналізу зворотніх посилань;
• інтеграції та розробки віджетiв;
• міжмодулева команда.

У складі кожної команди є відповідальний проектний менеджер та два-три розробники, один з яких — Developer Master.

— Які інструменти розробки використовують у вашій компанії?

Ми розробляємо на PHP, Python та JavaScript (React). Використовуємо такі технології, як Redis, RabbitMQ, Elasticseacrh, MySQL, Cassandra, будуємо сервіс-орієнтовану архітектуру. У нас вже є декілька мікросервісів, написаних на Symfony 4, PHP 7.2. Ці мікросервіси спілкуються за допомогою внутрiшнього SOA SDK — це наша власна розробка, яка дозволяє всередині одного сервісу звертатися до моделей іншого сервісу так, ніби вони знаходяться тут і зараз. Це можливо завдяки патерну проектування Proxy Object. Тобто це високорівнева абстракція над сервіс-орієнтованою архітектурою.

— Як виглядає процес розробки, життєвий цикл продукту?

Процес розробки починається з наших реквестерів, які записують у спеціальний документ побажання щодо удосконалення теперішніх інструментів Serpstat та вказують, яких інструментів не вистачає зараз, і було б добре, якби вони з’явилися. Потім задачу обробляє РМ того модулю, до якого відноситься побажання на впровадження зміни у сервіс. Він спілкується зі своєю командою розробників, дізнається про технічні деталі та створює так звану User Story — те, що побачать наші користувачi. User Story подрібнюється на декілька технічних задач, над якими безпосередньо будуть працювати програмісти.

Потім відбувається планування, на якому розробники оцінюють User Story у абстрактних одиницях складностi — сторіпоінтах. З таких User Stories складається план роботи на наступні два тижні — спринт. За ці два тижні команда набирає стільки задач, скільки вона встигне виконати. Закінчивши задачу, програміст передає її на код рев’ю до Developer Master команди. Якщо зауважень до коду немає, то таска потрапляє на тестування. Звідти вона повертається на доробку, якщо є баги, або закривається і потрапляє до релізної гілки і очікує релізу.

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

— Як прийнято проводити код рев’ю?

Код рев’ю проводиться відразу після завершення технічної роботи над задачею. Розробник створює merge request у репозиторій та переводить задачу на тімліда у Redmine. Тімлід виокремлює деякий час та механічно передивляється кожний коміт кожного розробника. Саме зараз ми впроваджуємо змiни в цьому процесi. Код рев’ю в мiкрокомандi буде проводити Developer Master, а йому код рев’ю буде проводити тімлід.

— Як прийнято проводити тестування, які тести застосовуєте?

Команда тестувальників складається з 9 спеціалістів. Процесс влаштований так: задачі потрапляють на тестування, QA Lead розподіляє їх серед команди для ручного тестування. У кожній задачі є definitions of done — критерії, за якими задача вважається виконаною. Тестувальники перевіряють, чи все виконано згідно з ТЗ постановника, та відмічають галочками definishens. Якщо є невідповідність, задача повертається на доопрацювання.

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

Сервiси, які написані на Symfony, покриваються юніт-тестами. Це тести, якi пишуть самі розробники, коли вносять правки у код чи розробляють нову фічу. Такi тести дозволяють переконатися в атомарнiй цiлiсностi коду до того, як задача потрапить до QA-відділу.

— Як відбувається розгортання (деплой)?

Ми дотримуємось парадигми Continuous Integration (CI), тобто код не потрапляє одразу на продакшн. У нас є буфер, куди складаємо код виконаних задач до релізу. Потім ці задачі викатуються на прод. Для цього в нас є такий інструмент, як Jenkins. У ньому написані джоби, які виливають на прод Back-end, Front-end і мікросервіси нашого продукту.

— Як проходить типовий робочий день розробника вашої команди?

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

Раз на тиждень СЕО проводить загальні збори усієї команди, де презентує визначні результати команд. Також вітають з днем народження, підвищенням коллег, проходженням випробувального терміну або усілякими приємними дрібничками.

Наприкiнцi спринта ми проводимо ретроспективу, на якiй кожен висловлює:

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

— Скільки годин на день працюєте?

У нас стандартний восьмигодинний робочий графік та одна година обідньої перерви о 14:00. Протягом робочого дня можна відлучатися для особистих справ, повідомивши керівника.

Можна приходити в офіс хоч о 8-й ранку, хоч о 10-й та виходити з офісу 5-й вечора чи працювати скільки заманеться, якщо розробник не хоче кидати незакінчену роботу. У такому випадку цей час рахується як робочий. Проте ми проти овертаймів, бо це погано впливає на зосередженість та продуктивність наступного дня чи цілого тижня. Краще пiти додому та використати вiльний час для саморозвитку.

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

— Хто у вашому випадку є замовником, як влаштована комунікація?

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

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

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

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

Див. також: Як це — бути розробником в Intellias, Genesis, SimCorp та Splynx.