×Закрыть

10 вещей, которые мы узнали при построении технологической компании

Build image via Shutterstock.

[Об авторах: Николай Палиенко — со-основатель и CEO в Prom.ua, Тарас Мурашко — со-основатель и CTO в Prom.ua]

В этом посте мы — бывшие разработчики — хотим рассказать о том, как мы набивали шишки, разрабатывая торговую площадку 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. Уделяйте больше внимания коммуникациям

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

15 комментариев

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

Ну и Николай забыл п.11 — ясные и прозрачные коммуникации с партнерами. С Вами (prom.ua) очень приятно иметь дело)

Да Евгений, тоже немаловажный пункт.

отличная статья! особенно п. 10

По поводу пункта 8: как дела сейчас обстоят, берете? и куда слать резюме)

Кроме того, у нас есть механизм демо-версий, когда мы собираем всех заказчиков перед релизом, и команда презентует функционал.

Вы на заказ работаете ?
Оутсорс ?

Заказчики чего? Ребята делают свой продукт!

Кроме того, у нас есть механизм демо-версий, когда мы собираем всех заказчиков перед релизом, и команда презентует функционал.

Заказ может быть и внутренним.
Какие-то заказы приходят от самих кастомеров через отдел поддержки пользователей.
Что-то заказывает отдел маркетинга.
Что-то — отдел продаж.

И для разработки, по большому счету, нет разницы: заказчик из другой компании в другой стране или коллега из другого отдела.

Зачем картинка такая жуткая? Да я визуал, пробачтэ.

Пункт 10 должен быть пунктом 1.

Штирлиц знал: запоминается последняя фраза...

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