×

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

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

Intellias

Тарас Кльоба, BI Team Lead на проекті EveryMatrix, Львів


Співробітників на проекті та в компанії: 10/1100.
Тип компанії: аутсорсингова.
Кількість деплоїв на день: 5.
Системна архітектура: Enterprise.
Операційні системи: Windows, CentOS, Ubuntu, macOS.
Бази даних: PostgreSQL, MySQL, MS SQL Server, Redis, Google BigQuery, ElasticSearch.
Чи можна працювати віддалено: можна після погодження з керівництвом.

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

Ми спільно із замовником розробляємо високонавантажену SaaS iGaming платформу, моделюємо системи аналізу та звітування, менеджмент ризиків, нарахування бонусів, а також створюємо конфігурабельні Front-end та мобільні інтерфейси.

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

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

Декілька моїх колег — це люди, з якими я працюю разом понад 5 років.

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

На нашому проекті основним сховищем даних є PostgreSQL, у якому ми зберігаємо терабайти даних. Ми використовуємо 10-ту версію і плануємо міграцію на версію 11 після релізу декількох проміжних версій.

Черга повідомлень реалізована на кластері Apache Kafka, які ми опрацьовуємо за допомогою Talend ETL та Python-скриптів. Для побудови звітів і Ad-hoc запитів використовуємо JasperReport Server.

Працюємо над міграцією наших потоків даних на Google Cloud. Зокрема, як сховище даних буде використовуватись Google BigQuery. Черга повідомлень буде організована за допомогою сервісу Google Pub/Sub. Типові ETL будуть замінені на Google DataFlow. Такий перехід суттєво розширить наші можливості й дозволить більше концентруватись на бізнес-цінності.

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

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

Загалом наша команда працює за методологією Scrum. У нас є спринти, щоденні стендапи, грумінг, планування, сторіпоінти тощо. Компанія-замовник працює за методологією SAFe.

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

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

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

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

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

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

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

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

Ми впровадили Continuous Database Deployment процес на нашому проекті. Це дозволяє після кожного збереження змін у репозиторії автоматично проводити тестування базової функціональності, мати повністю синхронізовані зміни на всіх середовищах, робити це централізовано у панелі GitLab CI/CD, отримувати можливість аудиту кожної зміни та бачити результати й успішність кожного деплойменту.

— Як проходить типовий робочий день розробника вашої команди? Скільки годин на день працюєте?

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

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

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

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

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

Мінуси: відсутність власних проектів.

Genesis

Микола Коваль, Senior Front-end Developer на проекті SocialTech, Київ


Співробітників на проекті та в компанії: 60/500.
Тип компанії: продуктова.
Кількість деплоїв на день: 1-2.
Системна архітектура: мікросервісна.
Операційні системи: Linux на серверах, MacOS — для роботи та Windows — для тесту.
Бази даних: PostgreSQL, MySQL, MS SQL Server, Redis, Google BigQuery, ElasticSearch.
Чи можна працювати віддалено: так, але завжди працюють в офісі. Ніщо не замінить живого спілкування.

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

Загалом у команді нашого проекту SocialTech працює 60 спеціалістів: розробники, продуктологи та маркетологи.

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

Ми працюємо в індустрії Social Discovery, де розвиваємо власні продукти, якими користуються мільйони людей по всьому світу.

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

Використовуємо Docker, Docker Swarm, GitHub, Kubernetes, Scrutinizer, Helm, GoogleCloud, Figma, Sketch, Illustrator, PhotoShop, Android Studio, Xcode, PHPStorm, Grafana, Jenkins.

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

Back-end в більшості написаний на PHP. Сильно навантажені мікросервіси — на Golang та інші поступово переводяться на цю мову.

Front-end: HTML5, CSS3, JS (ES8), деякі проекти на TypeScript. Поступово додаємо типізацію в інші проекти. Нативні мобільні додатки — Kotlin та Swift, напівгібридний — React Native, аналітичні системи — Python.

Також застосовуємо Node.js, SQL та Bash.

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

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

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

Перед проведенням код рев’ю пул-реквест з GitHub пропускається через CI сервер: на фронті це — ESLint, на PHP — Scrutinizer. Якщо все добре та всі тести виконуються, команда проводить рев’ю.

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

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

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

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

На систему розгортання було витрачено декілька місяців розробки. Це процес складний, але надійний. При пуші в репозиторій запускається автоматична збірка, яка збирає образи, оновлює кластер, запускає тести, code intelligent K8s, картинки в Docker Hub. Ingress перенаправляє трафік між подами, запускає джоби та вимикає старі поди.

Деплоїмо зазвичай до 14:00 з понеділка по четвер, щоб на вихідних та вночі не ловити баги.

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

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

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

Працюємо 8 годин. Але зазвичай в офісі проводимо більше 9 годин (оскільки час ще йде на сніданок, обід, «зробити паузу», «подрімати», навчальні мітапи). Буває і 10+ годин роботи, але до цього ніколи ніхто не примушує. Все залежить від власної мотивації та цікавості задачі.

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

Команда розробки постійно слідкує за новими рішеннями та інтегрує їх. Проводимо щотижневі навчальні мітапи по категоріях Back-end, Front-end, DevOps — таким чином обмінюємось знаннями.

SimCorp

Сергій Харченко, Senior Developer на проекті SimСorp Dimension, Київ


Співробітників на проекті та в компанії: 10/220+.
Тип компанії: продуктова.
Кількість деплоїв на день: 5-10 передрелізних деплоїв, у «гарячі» дні до 30-ти. Релізи, які йдуть у продакшн, звісно, виходять рідше.
Системна архітектура: десктопна частина має багаторівневу архітектуру з такими компонентами, як UI, Application, Data Access, Authorization. Cloud-додатки мають мікросервісну архітектуру.
Операційні системи: Windows OS.
Бази даних: Oracle, MS SQL, NoSQL (Cosmos, Mongo).
Чи можна працювати віддалено: так, якщо є така необхідність. Переважну більшість робочого часу ми працюємо в офісі для того, що ефективно взаємодіяти зі своєю командою та колегами у інших локаціях Product Division.

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

Наша команда є в якомусь сенсі унікальною в SimCorp UA: ми є частиною технічного департаменту, що займається розробкою ядра нашого продукту SimСorp Dimension та його ключових функціональних можливостей, які потім використовуються іншими командами для розробки бізнес-функціоналу. Це означає, що ми є першими, хто пропонує та запроваджує використання нових технологій у розробці продукту.

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

Тож команда у Києві займається розробкою веб-продуктів та фреймворків, які у майбутньому будуть фундаментом подальшого розвитку SimCorp Dimension, відповідно до Cloud-стратегії компанії.

Зараз команда складається з 10 спеціалістів: 4 розробника, 2 DevOps-інженери, по одному manual QA, QA automation, Scrum Master та UX-дизайнер. Компанія має великі амбіції щодо Cloud розробки, і зараз ми суттєво розширюємо команду. Welcome.

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

Ми працюємо у SAFe (scaled agile framework), в компанії запроваджені методології Agile-розробки. Ми використовуємо V1 для трекінгу, Slack та продукти Microsoft для комунікації, а також Git та TFS, TeamCity, Microsoft Azure та багато інших. У нас завжди вітається ініціатива «try something new», тому ми багато експериментуємо з вибором нових інструментів.

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

Більша частина існуючого десктопного продукту написана на мові APL, частина модулів — на C#. Для розробки нового веб-функціоналу використовуємо C#, TypeScript, JavaScript та такі фреймворки, як .NET Core 2.0, Angular 6.

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

Весь процес розробки відповідає SAFe. Спочатку продакт-менеджери разом з командами готують фічі. Потім на PIPE (program increment planning event) кожна з команд бере фічі у роботу. Розробка проходить у тісній взаємодії з продакт-менеджментом. Цикл розробки — двотижневий спринт.

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

SimCorp є продуктовою компанією, відтак ми зацікавлені у високій якості коду, адже він з нами «назавжди». Використовуються практики Joint code review, парне програмування — це дозволяє залучити більше членів команди до процесу розробки та рев’ю.

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

Для існуючого десктопного продукту переважно використовуємо внутрішні інструменти для створення автоматизованих тестів. Для тестування веб-функціоналу використовуємо тестування endpoint (XUnit), інтеграційне (Protractor, SpecFlow) та юніт-тестування.

Тестування, так само як і код рев’ю, інтегроване у процес розробки.

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

Середовище для тестування розгортається у Azure WebApps за допомогою пайплайну TeamCity. Наразі для production-деплою ми імплементуємо підхід Infrastructure As Code, з підготовкою Docker-контейнерів, що розгортаються у preproduction-кластері Kubernetes, а потім разом з усіма залежностями переходять до production-кластеру. Залежно від специфіки веб-продукту використовується Canary або Blue-Green тип розгортання.

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

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

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

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

Для нашої команди замовником може виступати як інша команда, що потребує від нас певного функціоналу, так і клієнт, з яким, у цьому випадку, комунікує продакт-менеджмент.

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

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

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

Зараз ведеться активний рух в напрямку Cloud технологій. На жаль, процес розробки відбувається не так швидко, як нам би цього хотілося. Адже Simcorp Dimension є масштабним продуктом, що потребує зважених архітектурних рішень та узгоджень з усіма стейкхолдерами.

Splynx

Руслан Малімон, CTO стартапу, Прага-Рівне


Співробітників у компанії: 24, з них 11 розробників.
Тип компанії: стартап.
Кількість деплоїв на день: 5-10.
Системна архітектура: моноліт + доповнення.
Операційні системи: Ubuntu, Debian.
Бази даних: MySQL, Redis.
Чи можна працювати віддалено: так.

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

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

Сьогодні такі додатки, як Splynx — це ядро роботи провайдера, business-critical, як-то кажуть. У користувачів інтернету нульовий поріг лояльності, і якщо система має баги, то сервісний центр провайдера за лічені хвилини перетвориться в гарячий котел.

Splynx — це потужний набір модулів та відкриті інтерфейси додатків (API), тому ми називаємо це Framework. Для адміністраторів це означає практично необмежені можливості налаштування програмного забезпечення і відповідно стабільну роботу мережі.

Наразі Splynx підтримує роботу близько 300 провайдерів із різних країн, як економічно розвинених (США, Австралія, Англія, Іспанія, Канада), так і країн, що розвиваються (ПАР, Кенія, Непал, Албанія, Чилі, Колумбія, Мексика). Відповідно, у кожного провайдера своє законодавче поле (для прикладу, GDPR в ЄС), різні типи підключень в мережі (PPPoE, DHCP, IPoE, Hotspot, Wireless або Static IP/MAC), технічні можливості, обладнання, бухгалтерські та платіжні системи. Щоб забезпечити потреби кожного провайдера, ми розробляємо додаткові модулі для інтеграції.

Ми постійно працюємо над удосконаленням платформи. Нещодавно вийшов новий реліз 2.2, у якому додали ще більше корисних функцій. У подальшому плануємо додати власну CRM-систему та розробити мобільний додаток, щоб мережеві інженери мали доступ до Splynx в «полях».

У стартапі працює 11 розробників рівнем від Junior до Senior PHP.

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

Для внутрішнього спілкування — Mattermost. Для відслідковування завдань — Jira.

Для управління вихідним кодом використовуємо Git, як централізований сервер репозиторіїв — Bitbucket. Кожну задачу ми розробляємо в окремій гілці Git, що названа так само, як і завдання з Jira. Це дозволяє легко співвідносити зміни до вимог.

Коментарі в commit також мають номер завдання, щоб комміти відображалися в Jira Worklog. Виконані завдання переносяться (мержаться) в гілку development, а звідти — в момент релізу — в гілку master.

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

Основна мова — PHP. Також є модулі, написані на JavaScript.

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

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

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

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

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

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

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

Автоматичні тести у нас розробляють як програмісти (unit-тести), так і тестувальники (з використанням, наприклад, Codeception). У якості сервера інтеграції та безперервної збірки ми використовуємо Jenkins.

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

Створюються deb-пакети.

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

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

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

У нас стандартний 8-годинний робочий день. Тімлід іноді працює більше.

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

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

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

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

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


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

Якщо хочете взяти участь у наступних випусках рубрики, пишіть на [email protected].

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




17 коментарів

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

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

Где-то глубоко внутри меня старый, циничный наемник, облокотившийся на ящик с расстрелянными боеприпасами, ехидно заявил, что попахивает корпоративным булшитом.

+1, с такими фразами по факту там на реальный ремоут будут косо смотреть, даже если кто-то захочет. Как с unlimited vacation, в общем).

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

-1, это другая крайность.

О, пополню ЧС ) Спасибо, что акцентировали внимание.

А то ведь они сами в свой корпоративный буллщит со временем начинают свято верить, отчего ХРши, как самые подверженные внушению копропротивных ценностей особи, вообразив, что у них возможна удаленка, начинают звать на собесы заядлых удаленщиков, где, собственно, и начинается цирк с конями и веселые игрища в буллщит-бинго, мол, — ой, а у нас удаленка, да, но лучше хотя бы на пару часиков в день притаскиваться в офис, коллектив же, синергия, командный з̶а̶п̶а̶х̶ ̶н̶е̶м̶ы̶т̶ы̶х̶ ̶н̶о̶г̶ ̶в̶ ̶д̶у̶ш̶н̶о̶м̶ ̶о̶у̶п̶е̶н̶с̶п̶е̶й̶с̶е̶ дух и бла-бла-бла, пофиг, что на дорогу больше времени уйдет; ой, а почему нет? ой, а откуда вы?
FFFFUUUU.....

Если в команде профессионалы (и это касается не только разработчиков)

Очень не хочется ссылаться на усатого, но фраза «Других людей у меня для вас нет» обычно приписывается ему.

Умение продуктивного удалённого взаимодействия — это отдельный скилл. И если тебе достаётся команда (неважно, коллеги или подчинённые), которые этого не умеют, можно сколько угодно обзывать их не-профессионалами, но придётся с ними работать.
А как такому учат, какой процент успеха в обучении, какие причины у тех, кто не сумел — у меня данных нет, но и у вас вроде тоже.

Моя первая серьёзная работа была там, где территориально было 3-4 места, включая ремотные места личного дежурства, и основное взаимодействие было через почтовые рассылки. И да, я могу так работать. Но и то я не уверен, что периодические сборы на нарады вживую не улучшали бы решение вопросов.

Figma, Sketch, Illustrator, PhotoShop,

Это как вообще? Все вместе? Или кто в чем хочет, в том и рисует? Ладно, в иллюстраторе свгшки можно рисовать, но остальное?

У нашій команді 10 людей, серед них немає розробників рівнем нижче Senior. Це дає низку переваг

Есть мнение (не моё), что команда из 5 синьоров может быть менее эффективной, чем состоящая из джуна, двух мидлов и двух синьоров. Потому что команда из 5 синьоров будет больше ругаться об архитектуре и о том, кто прав, чем педалить.

Лучше дополнительно опрашивайте бывших сотрудников, и желательно, обычных работников, а не лидов — больше вероятность, что напишут всю правду о том, как «быть разработчиком в * компании».

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

Тому краще опитувати і тих, що працюють і тих, хто пішов — тоді можна скласти більш-менш адекватне враження про компанію.

так потому и написано «дополнительно», а не вместо

Бачу, дякую, не одразу помітив.

Не варта коментувати коли хворієш...

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

взаимодействие в команде

Вот именно. Для этого и нужно так же спрашивать обычных работяг (собственно — разработчиков), а не менеджерское звено. Какой менеджер распишется на ДОУ в том, что он плохо организовует это взаимодействие? Или что рабочая среда — вся «на костылях», несмотря на красивые и модные названия технологий.

Да и в принципе,

Як це — бути розробником в *

фраза больше об людях, как мне кажется, а не о технологиях на рынке. В этом случае, назвали бы как-то вроде «Технологiї, якi застосовуються в *».

Насчет разработчиков — согласна. Но Вы ранее подчеркнули именно слово БЫВШИХ — к этому и было мое возражение.

Бывших — тоже нужно. А иначе — однобокая картина получится.

Системна архітектура: мікросервісна.
На систему розгортання було витрачено декілька місяців розробки.

Интересно начали бы сейчас опять проект на микросервисах или написали бы обычный монолит в 2 раза быстрее?

начали бы сейчас опять проект на микросервисах

Только хипстеры начинают сразу пилить микросервисы.

Увы, но там и так практически монолит, только сетевой (

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