Testing Stage’19: Technical | Security | Management and Approach — Early bird till 21 Dec. Hurry up!
×Закрыть

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

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

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

Depositphotos

Евгеній Слюсаренко, Team Lead команди з розробки сайту, Київ


Співробітників на проекті та в компанії: 11/400.
Тип компанії: продуктова.
Кількість деплоїв на день: 3-4 рази на тиждень, намагаємося не деплоїти в п’ятницю :)
Системна архітектура: API на PHP + MySQL, ізоморфний додаток на JavaScript на Front-end, а також сервіси і мікросервіси.
Операційні системи: Solaris, Linux.
Бази даних: MySQL, PostgreSQL.
Чи можна працювати віддалено: так, іноді можна, але не на постійній основі.

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

Відділ розробки складається з декількох скрам-команд. В нашій команді 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

Олександр Пригун, Team Lead C# на проекті з розробки білінгової системи, Одеса


Співробітників на проекті та в компанії: 24/150+.
Тип компанії: аутсорсингова.
Кількість деплоїв на день: до 5.
Системна архітектура: мікросервісна, більше 20 сервісів.
Операційні системи: MS Windows 2016 Server, Ubuntu 16.
Бази даних: MS SQL Server.
Чи можна працювати віддалено: в основному для спрощення комунікацій ми намагаємося працювати в офісі. Дистанційна робота також допускається, але не на регулярній основі.

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

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

Команда включає в себе три групи розробників, загалом 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

Дмитро Юнчик, Project Manager проекту Live Home 3D


Кількість співробітників на проекті та в компанії: 7/30.
Тип компанії: продуктова.
Кількість деплоїв на день: поставляємо апдейти раз на кілька місяців або негайно, коли щось вкрай необхідне.
Системна архітектура: монолітний застосунок.
Операційні системи: macOS, iOS, Windows 10.
Бази даних: mySQL на веб, безпосередньо у розробці продуктів не використовуємо.
Чи можна працювати віддалено: зазвичай ні, але можливо в окремих випадках.

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

У нашій компанії близько 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

Александр Майстренко, СТО компанії


Кількість співробітників у компанії: 30/80+.
Тип компанії: продуктова.
Кількість деплоїв на день: раз на два тижні, оскільки в нас CI.
Системна архітектура: сервіс-орієнтована архітектура, де є головний сервіс — Serpstat та декілька мікросервісів, які виконують свої ролі.
Операційні системи: Unix-системи.
Бази даних: MySQL, Elasticsearch, Cassandra.
Чи можна працювати віддалено: ми працюємо з віддаленими Front-end програмістами, але віддаємо їм тільки легкі задачі та ті, що не підлягають під NDA.

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

У нас один продукт — 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.

LinkedIn

22 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
Краще пiти додому та використати вiльний час для саморозвитку.

А могу я в нерабочее время отдохнуть?

Обід починається для всього Serpstat одночасно о 14:00

Я не хочу никого обидеть, но... это офигеть как странно. Вы ж не на заводе

Вообще, эта рубрика — прекрасный способ отсеять потенциальных работодателей

Там еще есть кое что странное ))

Розробник може прийти з 8-ї до 10-ї години та вiдмiчається у внутрішній CRM.

Какой однако удобный гибкий график! xD Хочешь — можешь в 8 прийти, а хочешь — в 10! )))

Вангую, что эта внутренняя CRM еще и время трекает.

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

Якщо хочете жити по графіку, то будь ласка — живіть, але не всім же довподоби таке. Що заважає продуктовим ІТ компаніям піти назустріч людям і зробити графік більш гнучким? Апелювати до банків\фабрик нерозумно, краще приводити сильніші аргументи.

Разрабы против не фиксированного графика как такового, а против первичного обещания ГИБКОГО графика, который оказывается нефига не гибкий.

Заставляют на работу по графику ходить — смех какой, где ж это видано такое./blockquote>
А еще бывает заставляют переработать чуток (баг в пятницу вечером на проде). И сяду я без проблем часик сверху посижу, исправлю. А был бы на заводе — в 5 вечера в подсобке бы уже переодевался. И хрен бы до меня начальник дозвонился в субботу при острой необходимости.
Поэтому это палка с двух концов ;)
большинство людей и того не имеют.

А где -то в Африке дети голодают, представьте ? Кошмар, а мы тут печеньками на кухне перебираем.

на работу по графику ходить

Я хожу на работу не по графику, а для того чтобы качественно и в срок выполнять свои обязанности. И если я это делаю, то компании все равно, пришел ли я в 8, 10 или в 12. Главное — результат. Другое дело — эффективная работа с командой, чтобы ей это не мешало, и мы эффективно работали вместе, присутствовали на необходимых митингах, и был результат работы. Если результат работы хреновый, то хоть по графику приходи, хоть строем — смысла от этого мало.

Другое дело, что это засисит от самодисциплины. Есть и такие, которым нужен надсмотрщик и погонщик, бьющий хлыстом над ухом, и заставляющий включать трекинг нажатий на клавиатуру, без этого человек не перформит. И таких людей видел, но старался с ними работать.

А где -то в Африке дети голодают, представьте ? Кошмар, а мы тут печеньками на кухне перебираем.

это не кошмар, это просто фарт и ничего более — получать печеньки и несколько килобаксов за формошлепство, и насмехаться с работодателя, который дает 2х часовую вилку что бы утром прийти на работу.

просто фарт и ничего более

Фарт в чем ? Фарт — это родиться мажором, или выиграть в лотерею, или откопать на огороде сундук с золотом. А работа на иностранного заказчика — это результат труда и постоянной работы над собой.

формошлепство

Ну, кто чем занимается. В этом плане я вам сочувствую.

Фарт в чем ? Фарт — это родиться мажором, или выиграть в лотерею, или откопать на огороде сундук с золотом. А работа на иностранного заказчика — это результат труда и постоянной работы над собой.

Да-да, я это и имел виду. А зарплаты по рынку тому отличное подтверждение. Вот протрудился\сомосовершенствовался до 23х лет и стал интернет мемом.

В этом плане я вам сочувствую.

Ну вы очень рано перешли на личности. :) вы же причисляете себя, судя по постам выше, к «самодисциплированный», а не сдержались на втором посту.

По поводу

перешли на личности

ИМХО вы это сделали раньше, когда начали проецировать на итшников и на меня в том числе вот это вот все

формошлепство,
фарт и ничего более

Если у вас негативные эмоциии в сторону современных разработчиков и у вас подгорает что какие -то парнишки, в обед играя в железную дорогу, получают гораздо больше других ( вот они то уж точно вье@ывают! ), то это лучше изливать лежа на кушетке у психолога а не на форуме.

«самодисциплированный»

и нетерпимый к чему — то это разные вещи. В данном случае — к точке зрения, которая кроме как эмоциональным фоном, больше ничем не подкрепляется

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

Вы простите, что вмешиваюсь в Ваш диалог с Антоном.
Тут основной момент в том, что по факту работа разработчика не нормирована. Причем часто — очень сильно.
То есть он легко может в неделю отработать и 50 и даже 60ч.
Часто — без компенсаций. Отсюда и берется желание срезать временные потери, часть из которых на утро и приходится.
Ведь тут так — если работодатель требует корректного и строгого прихода на рад. место, это его право и это нормально.
Но права тянут за собой и обязанности. Работодатель в таком случае должен подать и работу. а не в стиле «Приходите на 10 а задачи будут после митинга в 13, ну и работать Вы будете о 22, 8 то часов надо отмахать».

Но права тянут за собой и обязанности. Работодатель в таком случае должен подать и работу. а не в стиле «Приходите на 10 а задачи будут после митинга в 13, ну и работать Вы будете о 22, 8 то часов надо отмахать».

Зависит опять от модели сотрудинчества на которую вы даете согласие — если у вас fixed price я ожидаю, что работу вы уже получили и за вами никто не следит(сколько в день работаете), если T&M то бильте свои фактически отработанные часы, а не по принципцу работаю 4 трекаю 8. Ну что разве вам это заказчик позволяет и всем доволен. С точки зрения профессиональной этики, скорее всего, вы все равно не правы будете. В случае если вам заставляют сидеть больше, чем оплачивают — то либо ожидания у заказчика завышенные, либо вы не дорабатываете, в любом случае можете сменить проект, у нас же рынок в этом плане достаточно гибкий.

но старался с ними работать

пропустил НЕ :)

Существуют разные подходы к работе и организации процессов.
Каждый волен выбирать то, что ему по душе.
Мы выступаем за чёткость и быстроту коммуникаций, что достигаетася когда все находятся в офисе и любой вопрос можно решить вживую, значительно быстрее, чем в переписке. Если кому-то не нравится работать в офисе или приходить в определённое время, то, естественно, наша компания ему не подходит.
Но если вам нравится порядок, структура и чёткость, тогда мы один из самых подходящих работодателей по этим критериям.

Да вы прям чёткий работодатель для чётких пацанов :)

достигаетася когда все находятся в офисе и любой вопрос можно решить вживую, значительно быстрее, чем в переписке

Сказкі о голубоґлазкє.

Переписка лишає після себе цінний артефакт у вигляді хісторі, до якої можна повернутися, перечитати, розшарити з послідовниками в оригінальному вигляді, а не а-ля «Рабіновіч Моцарта напєл».
Любителі ж живого, хай йому трясця, спілкування, 80% часу ходять по колу, з’ясовуючи одне й те саме при різному складі співрозмовників, та банально забуваючи щось із раніше з’ясованого. Але так, часто погонщику зі сторони здається що все швидко та ефективно вирішується, оскільки неозброєним оком видно бурну діяльність. Угу.

Всім ярим любителям обговорень «вживу», завжди рекомендую відмовитися від використання Джири або аналогів, а таски видавати одразу з голови о̶р̶а̶л̶ь̶н̶о̶ вербально прямо під час спрінт пленінгу. Нє, ну а чо? Адже так «значітєлна бистрєє» ))

Делюсь лайфхаками:
1. Любой митинг (встреча, обсуждение) не должен длиться больше часа.
2. Любой митинг (встреча, обсуждение) должен заканчиваться письменным followup’ом на почту всем участникам.

При соблюдении этих простых правил, тех проблем, которые вы описали, не будет.

Не очень понятно кого вы называете «погонщиком» . У нас продуктовая компания и «погонщиков» у нас нет

У нас продуктовая компания и «погонщиков» у нас нет

новый мем однозначно в мемориз ящетаю ))

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