Компетенції
Ми створюємо продукти, які вирішують безпосередньо бізнес задачу
Чому вкрай важливо бачити картину в цілому
Продуктивніше за все співпрацювати із нами, якщо ви хочете делегувати прийняття і продуктових, і технічних рішень. Водночас, ми ніколи не запропонуємо свої послуги, якщо будемо знати, що інша відома нам компанія зробить це краще. Найпродуктивніше працювати з нами, якщо продукт складається з кількох складних задач, що потребують розуміння декількох типів технологій. В проєктах наших клієнтів вкрай важливо бачити картину в цілому, а саме у цьому ми є досконалі.
Типи технічних задач та
предмети розробки
Веб-застосунки
Особливостей задачі може бути безмежна кількість, і ми готові до специфіки кожного проєкту. Ми вміємо виокремити головне, прикласти зусилля тільки до важливих точок і досягти очікуваного результату.
Ми багато разів реалізовували задачі кожного напрямку, доводячи їх до production. Створення кастомних CMS для неординарних задач, інтеграції з найбільш проблематичними 3rd-party, побудова і реалізація складних сценаріїв CJM, унікальні самописні функціональності, безпечні і нетипові схеми отримання оплат, нестандартні SSO. Усі ці задачі для нас є типовими, і через це ми вміємо правильно розставити пріоритети, вписатися у найскладніші обмеження і успішно випустити продукт.
Архітектура та високонавантажені рішення
Якщо ключові слова з заголовку — про вашу задачу, ми переконані, нам варто це обговорити. Саме у таких задачах ми найбільш продуктивні.
Ми пишаємося не тим, що вміємо говорити просто про складне, а тим, що наші слова скоро стають реальністю. Ми мали проєкти з сотнями бізнес-сутностей, десятками репозиторіїв, мільярдами записів у таблицях баз даних, сотнями запитів до наших серверів на секунду. І ці проєкти успішно виконували свої задачі, бо ми дійсно вміємо передбачати приховані проблемні місця у кожному нашому продукті. Та, врешті, готувати їх до зіткнення з реальністю.
ІоТ, серверне ПЗ, застосунки з нетиповою структурою
Ми працюємо безпосередньо з задачею; інструментарій для її розв'язку, по суті, не є важливим. Відтак ми можемо розробляти рішення для вас, коли середовище, в якому функціонує програмний продукт, може бути зовсім незвичним.
Ми добре знайомі з великою кількістю платформ, інструментаріїв, фреймворків. Завдяки нашому широкому нетворку ми вміємо достатньо швидко підсилити команду потрібною експертизою. Ми можемо однаково успішно написати ПЗ для каси, дрона, робота на Arduino чи розумного термостата. Головне, щоби ми з вами впорались чітко сформулювати підсумкову цінність вирішеної задачі. Ми не маємо «філософського каменю» для вирішення будь-якої задачі. Тільки здоровий глузд і життєвий досвід. Ми не прагнемо знати усі мови програмування і фреймворки на світі, ми не женемося за технологіями тільки через їх трендовість. Але кожен технічний лідер нашої команди — це не просто успішний митець у своєму технологічному стеку. Це людина, яка розуміє суть розробки і вміє в кожній ситуації притомно оцінити власні сили і запропонувати найкраще рішення. Це рішення завжди залежить від великої кількості обмежень бізнес-задачі. Його ми приймаємо, зважаючи на кінцеві цілі нашого клієнта.
Мобільні застосунки
Часто при розробці мобільного застосунку головна задача полягає у побудові правильного досвіду користувача і якісному вирішенні проблеми кінцевого споживача. Саме у цьому випадку ми готові привести вас до найкращого результату.
Нерідко задача виглядає настільки неоднозначно, що складно визначити фокус. Як і в інших типах застосунків ми вміємо проаналізувати вимоги і з позиції бізнесу, і з технічної точки зору. Як результат, ми обираємо для вирішення найбільш своєчасні задачі, успішно виконуємо їх та випускаємо застосунок.
Конструкція технологічного стеку
Може здатися, що технології — це питання суто рівня команди розробки, й воно не впливає на продукт в цілому. Ми не можемо погодитись з такою думкою. Саме інструментарій створює об'єктивні межі для продуктивності процесів розробки. Відтак він має бути вибудований з повним розумінням усього спектра задач, які можуть зустрітися у процесі розвитку продукту.
Підхід до побудови технічного стеку
Мови програмування
Python — наш стандартний вибір для більшості задач. Ми обрали цю мову основною, тому що стеки навколо неї оптимальні для всіх проєктів ранніх стадій, і ми довели це на практиці. Наш основний фреймворк — Django. Деякі back-end задачі ми вирішуємо на PHP і C++, бували випадки навколо NodeJS. Front-end задачі ми вирішуємо за допомогою Vue та React. Задачі мобільної розробки — Kotlin і Swift. Якщо ваш проєкт потребує експертності в інших мовах — найімовірніше, це не стане проблемою для нас.
Справа зразок типової підсистеми та мов програмування, використаних для її розробки.
Система управління Базами даних
СУБД, що превалює в наших проєктах — PostgreSQL. Передусім через те, що ми добре вміємо застосовувати реляційні СУБД в усіх повсякденних випадках, що, на нашу думку, повинна вміти кожна компанія, яка займається розробкою.
Ми добре знаємо її внутрішні механізми, принципи і вміємо «приготувати» її за сотнями різних рецептів. Траплялися задачі, завдяки яким ми добре знайомі з MongoDB та Redis. Якщо проєкт потребує або залежить від MySQL, Oracle чи MS SQL (наприклад, інші робочі застосунки використовують їх) — це не є проблемою.
DevOps
Для проєктів ранніх стадій найважливішим є вірно відбудований CD, тому що релізи мають бути частими і безболісними. Вони можуть містити суттєві зміни продукту не лише на рівні схеми даних, але аж до повної реорганізації структури застосунку і взаємозв'язків. Ми своєчасно і обґрунтовано плануємо введення автотестів на продукті, тому ми знайомі з усіма популярними CI-рішеннями. Іноді наші рішення потребують кастомної розробки портативних образів комплексних застосунків, тому ми добре володіємо docker. Це зовсім не повний перелік наших класичних інструментів. Ми маємо багато готових рішень й широку експертність для вирішення кожної задачі.
Процеси розробки
Якщо процеси слабкі, то проєкт, ймовірно, помре рано через їх відсутність. Якщо процеси придушують суть продукту, то він неминуче потоне в них, в результаті буде загублена його сутність. Ми вміємо довго і оптимально балансувати у цих рамках. Ми не запровадимо backlog, code review, routine checkup на продукті, доки ви не будете чітко знати, для чого вони потрібні. Водночас, якщо вони потрібні, ми точно зможемо пояснити їх доцільність і проілюструвати це на прикладах.
Досвідченість у мовах програмування, середовищах, стеках технологій робить нас сильною компанією з розробки ПЗ. Проте наша найсильніша сторона не у цьому. Ми вміємо робити продукти, які допомагають нашим клієнтам заробляти більше. А для цього потрібне дещо більш значуще. Ми називаємо це принципами продуктової розробки.
Принципи продуктової розробки
В індустрії нині не існує універсальних принципів продуктової розробки. Будь-які методології повинні застосовуватися виключно з урахуванням прикладних складників. Через це ми можемо спиратися лише на здоровий глузд у цьому питанні. Нашим клієнтам цього цілком достатньо. Нижче наведено кілька підходів, які ми використовуємо для побудови стратегії розробки продукту.
Прямуй за грошима
Ми ніколи не візьмемо в роботу суттєвий блок задач, доки його економічна рентабельність є сумнівною. Ми дізнаємось очікування клієнта щодо ROI кожного блоку задач, навіть якщо їх важко сформувати. Якщо ми, після технічного аналізу, не будемо достатньо переконані, що наші роботи приведуть продукт до його розвитку, а його власників — до більш оптимістичних економічних очікувань, то, ймовірно, ми відкладемо ці роботи. Нам треба розуміти як інкремент в продукт приведе клієнта до прибутку, інакше наша праця виявиться марною. Ми вміємо слухати, діставати відповіді, аналізувати ситуацію, і тому впевнені, що візьмемося за розробку лише тих задач, які принесуть значну вигоду.
Кінцевий споживач
Результативний процес прийняття продуктових рішень потребує врахування думок усіх важливих учасників. Часто при розробці програмних продуктів компанії цілком покладаються на думку клієнта, недооцінюючи потреби кінцевого користувача. Крутий продукт не відбудеться без усебічного бачення усіх його аспектів. Ми не боїмося поділяти відповідальність з клієнтом, беручи участь в усіх стратегічних рішеннях як на його користь, так і на користь кінцевого споживача. У сфері нашої експертизи ми оцінюємо ймовірність успіху кожної гіпотези і боремося за зниження ризиків шляхом зниження невизначеностей. В суперечливих ситуаціях ми не будемо вносити в продукт сумнівні інкременти, доки не прийдемо до консенсусу. Ми можемо запропонувати альтернативи — економніші дослідження чи менш ризиковані тести гіпотез. Завдяки такому підходу ми робимо наші продукти більш життєздатними.
Контролюй архітектуру
При роботі з продуктом ранньої стадії, є розумним закладати часті зміни загальної стратегії, які викликають неминучі зміни архітектури продукту. Ми вміємо вибудувати концепт продукту на ранній стадії так, щоби він був максимально готовим до майбутніх змін, навіть маловірогідних. Головне у цьому процесі — розуміти вихідні причини зростання навантаження на будь-які місця продукту, і ми успішно з цим справляємося. Тому наші продукти майже завжди готові до значного зростання обмежень — у 10, 100, а якщо треба, то й у 1000 разів, часто без глибоких змін.
У випадках коли зміни бізнес-моделі потребують зміни принципів продукту, ми готові до такої ситуації. Ми покажемо клієнту комплекс чинників, через які ми робимо оцінку про необхідність архітектурного розвороту. Завдяки поінформованості клієнта про плани гіпотетичних архітектурних розворотів, ми часто можемо їм запобігти. І навіть коли продукт змінюється докорінно, ми не здаємося. Завдяки систематичній оцінці усіх факторів, ми запропонуємо що варто успадкувати від продукту, а що треба перебудувати з самого початку. Тому ми впевнені в раціональності ваших витрат на розробку. Взагалі, нам приємно, що наші клієнти витрачають менше.
