10 речей , які ми дізналися при побудові технологічної компанії

via Shutterstock .

[ Про авторів : Микола Палієнко - з-засновник і CEO в Prom.ua , Тарас Мурашко - зі - засновник і CTO в Prom.ua ]

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

1 . Шукайте нішу

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

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

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

2 . Користуйтеся аналітикою

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

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

3 . Масштабуйте з часом

Передчасна оптимізація коду - це зло. Хоч ми до цих пір багато в чому користуємося архітектурою , яка була розроблена 5-6 років тому , весь цей час наш код еволюціонував разом з навантаженнями і завданнями. Якщо чотири роки тому у нас було до мільйона переглядів сторінок на день , то зараз це 10 млн. тільки по Україні . Обсяг даних виріс на два порядки , і зараз перевищує 200 Гб. За весь цей час у нас не було значних революцій : спочатку з'являлася проблема , потім приходило рішення . Коли на старті у вас 100 осіб на день , не потрібно городити hi - load архітектуру. Зрештою , багато клієнтів - це приємна проблема , і її приємно вирішувати.

4 . Оптимізуйте// не забувайте правило Парето

Зараз ми почали розбивати на деякі частини наш спочатку монолітний продукт. Раніше даних було мало , і майже всі дії виконувалися в реальному часі. Сьогодні - їх настільки багато , що доводиться ставити операції в чергу. Ми оптимізували верстку , процедуру складання скриптів. Намагаємося зменшувати час завантаження , максимально прискорювати проект. Широко застосовуємо систему моніторингу . Використовуємо правило Парето , коли 20 % зусиль можуть вирішити 80 % проблем . Головне - знайти ці самі товсті відсотки .

5 . Структуруйте

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

6 . Вибирайте правильних співробітників

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

Був випадок , коли один і той же кандидат пробував потрапити до нас в команду розробки три роки поспіль , і тільки після того , як пройшов за нашими вимогами - став співробітником. Є і яскравий приклад , коли колега щодня протягом року їздив з Чернігова до Києва на роботу громадським транспортом і « намотав » за цей час 2 екватора , поки ми не переконали його переїхати до Києва.

7 . Не бійтеся переучувати з інших технологій

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

8 . Зростайте співробітників зі студентів

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

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

9 . Не бійтеся криз

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

10 . Приділяйте більше уваги комунікацій

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

Опубліковано: 26/05/14 @ 06:41
Розділ Різне

SEO Блог