×Закрыть

Кар’єра СТО в стартапі без прикрас

Мені часто доводиться спілкуватися з технічними співзасновниками стартапів і друзями-програмістами, які хочуть робити IT-бізнес. Граблі, на які наступають люди з технічним складом розуму, переважно схожі. Як і те, що картинка стартапу як ідеальної роботи для будь-якого програміста, не завжди відповідає дійсності. Я хотів би поділитися досвідом розбудови «кар’єри» у ролі CTO у стартапі Preply і деякими порадами з власного досвіду.

To be or not to be

Перше, що потрібно усвідомити перед тим, як починати власний технологічний бізнес, — систематичну помилку тих, хто вижив (survivorship bias). Всі історії успіху стартапів, про які ми читаємо в пресі, дізнаємося з ТБ чи чуємо від знайомих — це крапля в морі історій, яких ніхто ніколи не почує, — про людей, які почали створювати стартап, але в них нічого не вийшло.

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

Потрібно розуміти, що робота в стартапі — це не про гроші (принаймні в перші роки). Якщо основна мотивація — заробити кошти, то набагато легше піти в аутсорс або емігрувати.

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

Перші кроки

Рішення, які повинен приймати СТО на перших етапах — одні з найважливіших у стартапі. Саме тоді обирається фреймворк, мова програмування і технологічниий стек, на якому писатиметься проект.

На початку проекту часто виникає дискусія: чи почати писати проект на тому, на чому вмієш, чи взяти нову технологію. Перевагою першого варіанту, очевидно, є швидкість, проте другий варіант цікавіший з точки зору професійного розвитку. Мені доводилось працювати як з першим варіантом, так і з другим варіантом (освоював Groovy).

З точки зору побудови бізнесу, необхідно задати собі питання: «Чи зможу я на технології, яку вже знаю, побудувати таку архітектуру проекту, щоб на етапі росту проекту, команди і навантажень його можна було птимізувати/переписати/ефективно підтримувати?»

Якщо відповідь «так», то моя порада — писати на тому, що знаєте, а проблему професійного росту вирішувати поліглотною архітектурою мікросервісів. У нас основний проект на Python, проте вдало вибравши архітектуру з самого початку, ми вільно можемо писати функціонал на Java, JS, який комунікує з основним проектом через RabbitMQ. Рекомендую по темі безкоштовну книгу Сема Ньюмена.

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

На початковому етапі основна задача — це зарелізити MVP. Тут порада проста: швидко писати хороший код і ефективно вести комунікацію з колегами, які займаються бізнесовою частиною проекту. Частою є ситуація, коли бізнес-частина команди чекає тижнями чи місяцями, поки СТО і його команда напишуть код, а до того часу нічого для проекту не робить. Для СТО це перший red flag, що у команді є проблема. Бізнес-частина повинна робити «продажі» продукту до релізу. І бажано, щоб за реальні гроші. У нашому випадку, коли ми писали MVP, у нас була односторінкова посадочна сторінка — на неї падали заявки, а наш СЕО «ручками» обдзвонював потенційних клієнтів і робив продажі.

Другий істотний момент — це визначення фіч проекту. В силу того, що грошей у стартапа мало, так само, як мало і часу, а замовником продукту по факту виступає сама команда, важливо розуміти, які метрики вам важливі і які фічі на них можуть впливати. Для технологічних компаній, в яких основна мета — exit через придбання, важливо писати фічі, які вписуються в цю стратегію. Для компаній, що не монетизуються, важливий user base, для проектів на локальному ринку — важливо заробляти з першого ж дня і т.д.

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

Ще один важливий момент — накопичення «технічного боргу». Від цього не втечеш, але потрібно слідкувати за тим, щоб на початкових етапах не зробити критичних помилок в архітектурі. Раджу спілкуватися з СТО з інших проектів, які вже пройшли ваші етапи, або мати гарно підкованого ментора, який зможе підказати правильні рішення. Той спосіб, який працював для мене, — це регулярні обіди з СТО інших проектів, походи на мітапи, хакатони та інші події. Не треба забувати і про принцип give first і підтримувати колег з меншим досвідом, у яких є питання.

Також на ранніх етапах рекомендую звернути увагу на схему бази даних і регулярно говорити з колегами, які писали продукти, схожі на ваш. Погано підібрана схема даних означає необхідність міграцій даних і схем в майбутньому, а це далеко не найприємніший момент. Наприклад, у нашому випадку невірно підібраний спосіб збереження сум у різних валютах дуже неприємно докинув задач по мірі масштабування на інші ринки. В іншого «знайомого» проекту досі аукаються проблеми з даними, які містяться в MongoDB, адже NoSql — це не панацея від проблем зі схемою, якщо продукт набуває певної міри зв’язності.

Не завжди очікуваним моментом є також і те, що у малих командах роль СТО не обмежується лише написанням коду. Часом необхідно брати на себе інші речі, такі як налаштування корпоративної пошти, переустановлення операційної системи чи налаштування sip call-центру. Це рутина, до якої також треба бути готовим.

Етап росту

Як тільки вашим продуктом почне користуватися постійно зростаюча кількість користувачів, закономірно постане питання можливості витримувати навантаження, що збільшуються. Слід згадати слова Дональда Кнута: «Premature optimization is the root of all evil». Двічі подумайте, чи існує для вас така проблема. Загальне правило полягає в тому, що коди переписуються заново при зростанні навантаження на порядок. При лінійному зростанні часто ефективніше вирішувати проблеми навантажень вертикальним масштабуванням серверів і баз даних.

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

Прикладами таких задач є:

— Локалізація продукту. Українські стартапи приречені виходити на глобальний ринок, адже робити продукти для локального ринку недоцільно з економічної точки зору. Я часто помічав, коли колеги з інших проектів регулярно просять змінити якийсь текст на сайті внаслідок знайденої помилки локалізації або завантаження нових текстів на сайт. Базова імплементація continuous localization дозволить більше ніколи не витрачати час програмістів на рутинну роботу з оновлення перекладів текстів.

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

— Маркетинг. Винесіть редагування цільових сторінок в адміністративну частину сайту, налаштуйте інструменти, які забирають маркетингову роботу з програмістів, наприклад, Google Tag manager.

— Статистика. Помилка, яку часто допускають в стартапах — спроба писати внутрішню систему статистики (ми також цим хворіли). Це дуже неефективне використання ресурсів, адже практично неможливо передбачити всі метрики/розрізи. Рішення — вигрузка всіх сирих даних в спеціальні програми бізнес-аналітики.

— Адмінка. Налаштуйте права на редагування потрібних моделей для решти команди. Особливо добре, якщо ваш фреймворк підтримує scaffolding.

Потрібно приймати рішення, чи хочете ви розвинути в собі компетенції DevOps — часто можна викинути частину технічного адміністрування проекту, скориставшись якоюсь з систем PaaS, або залучати до команди відповідних спеціалістів. В силу технічних особливостей інколи потрібно мати глибший досвід в інфраструктурі. У нашому випадку важливий контроль на кожному етапі, тому прийшлося в процесі навчитися налаштовувати Nginx і VPN, розгортати Docker на серверах та робити інші, зовсім не програмерські задачі. З одного боку, це хороша можливість «прокачати» відповідні компетенції і глибше зрозуміти сучасні технології, проте, з іншого, це займає час.

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

Перевіряйте чекліст Джоеля Сполскі і закривайте речі, які ще не імплементовані. Дискусія допускається в пунктах про тести і документацію. Слід розуміти, що стартапи — це швидкість, і написання тестів може суттєво збільшити час розробки продукту. Часом ці затрати можуть окупитися, а часом ні. Інколи краще відмовитися від ідеї на 100% покрити продукт крихкими тестами, але потім при кожній ітерації їх правити. Натомість дійсно критичні частини продукту покрити стійкими тестами і компромісно закривати ті речі, які не будуть переписуватися.

Мій досвід пов’язаний з тим, що ми досить регулярно щось дописуємо/переписуємо, і я не є фанатом TDD. Моя логіка не в тому, що не потрібне 100% покриття, а в тому, що тести потрібно писати в певний момент часу, коли на це є ресурси. Особливо важливо почати писати більше тестів в той момент, коли до команди розробки долучаються нові люди. В процесі знайомства з продуктом вони можуть писати код, який щось ламає, а тести — ефективний інструмент на рівні з код рев’ю, який дозволяє локалізувати такі проблеми.

Бізнес

Інколи хтось з команди або знайомих мене питає: «Скільки часу ви ще будете стартапом? Вам вже три роки, а ви досі піаритесь». Логіка досить проста — ми стартап, поки відхід одного з співзасновників проекту являє собою критичний ризик того, що проект закриється.

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

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

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

Натомість всім відома PayPal мафія — спільнота колишніх працівників (не тільки співзасновників) PayPal, які на свої акції option pool створили купу успішних бізнесів і стали мільйонерами. Причому є купа інших менших «мафій». Наприклад, під час нашого перебування в Берліні ми познайомилися з ранніми працівниками ZenDesk, DeliveryHero, які також за допомогою акцій option pool уже зараз інвестують і роблять власні бізнеси.

Географічно ближчий приклад — польський стартап для пошуку нянь niania.pl, вихідці з якого зараз дуже активні в інвестиціях в Східній Європі і заснували кілька успішних бізнесів.

СТО повинен розповідати своїй команді такі історії, пояснювати цей інструмент. Тому що відчуття власності над продуктом (тим більше, коли вона юридично закріплена) — ідеальна мотивація команди. По мірі того, як будуть траплятися такі українські історії успіху, цей інструмент набуватиме все більшої популярності.

Окрім складних і цікавих задач, у програмістів завжди буде рутина. На етапі переходу від стартапа до зрілого бізнесу потрібно по максимуму автоматизувати всі задачі з розробки, мати хорошу внутрішню базу знань — тоді нові люди зможуть легко ввійти до стану справ. Процеси розробки потрібно краще документувати, тестування продукту стає важливим і невідворотним процесом. Якщо раніше one-click-deployment — це вже було добре, то тепер варто більше дивитись у сторону практик immutable deployment. Адже аварійні стани системи можуть бути не такими критичними для стартапу, проте набагато більш болючими для усталеного бізнесу.

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

Замість висновків

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

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

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

— Важливо бути в курсі сучасних технологій і по можливості впроваджувати їх в проект. Але потрібно насамперед роботи мінімальний аналіз cost/benefit зі сторони бізнесу. У нашому випадку ми розглядали можливість міграції з Backbone на Angular, але часові затрати були незрівнянно більшими за плюшки, які ми могли одержати. З іншого боку, ми аналізували переїзд з self-hosted PostGreSQL на Amazon RDB, і хоча це тягло за собою суттєві витрати часу, виграш від нової технології при масштабуванні був суттєво вищим.

Буду радий почути ваші думки або запитання в коментарях.


P.S. Якщо вам цікавий наш проект — ми регулярно шукаємо досвідчених Python-програмістів. Писати можна на preply.com/ua/help/contact.

LinkedIn

Лучшие комментарии пропустить

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

Мои аргументы:

1. Трафик стартапов растет не линейно, а скачкообразно. Попадание на «главную» Хабра, DOU или Product Hunt может увеличить количество запросов на несколько порядков.
Если база данных хранится в памяти и только периодически сбрасывается на диск, то приложение, очевидно, не являтся stateless и не может быть легко горизонтально масштабировано.
Вертикальное масштабирование сервера требует, как минимум, перезагрузки и во время пиковой посещаемости крайне нежелательно. И то, это возможно, если апп не хостится на bare metal сервер, а использует облако.
Этого, собственно, уже достаточно, чтобы не использовать память-жесткий диск. Стартап всегда должен быть готов к пиковым нагрузкам.

2. MVP обязательно предполагает наличие пользователей. В этом и есть суть MVP: протестировать value proposition и получить фидбек от реальных юзеров. Проверка возможности реализации технического концепта называется «proof of concept» и для большинства стартапов является тривиальной задачей.

3. Большинство MVP разрабатываются на динамических ЯП с использованием популярных MVC фреймворков: Rails, Django, Phoenix, различные варианты для nodejs. Создание датастора без базы данных увеличивает время разработки, а не сокращает его. Интеграция с базами данных в таких фреймвоках предоставляется «for free».

4. Валидация данных. Вместо того, чтобы использовать стандартную валидацию типов данных в SQL базах данных придется писать собственные хелпер функции. Вместо протестированного годами и миллионами деплойментов кода, за data integrity будет отвечать самописный велосипед. Где тут выигрыш?

5. Логично, что на этапе быстрой итерации постоянно менять схему данных неудобно. И для этого сценария существует формат jsonb для PG или RethinkDB, если хочется nosql и кластер. Подойдет даже Mongodb.

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

7. «Именно. Для >90% стартапов это[база данных] оверхед». Кто там говорил о профессиональной деформации?

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

Исходя из пунктов 1-8, считаю, что для подавляющего большинства стартапов и бутстрэпов оптимальным решением является использование PostgreSQL. До тех пор, пока эмпирически не доказано обратное.

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

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

Дуже гарна і корисна стаття — дякую.
Єдине, що насторожило, це ігнорування тестів на старті проекту. Я і деякі мої знайомі на цьому колись попеклись :) Можливо, коли бракує часу, то хоча б писати функціональні тести, ігноруючи чисто модульні?

Неймовірно крута стаття — як на мене, перекласти та опублікувати її англійською мовою — це «must-have», оскільки тема стартапів досить популярна зараз не тільки у нас і я думаю цю статтю будуть однозначно читати західні колеги.

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

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

Чувак «бізнес» це не завжди про гроші — для розуміння мотивації людей що роблять бізнес можна почитати наприклад «Атлант розправив плечі», більше того я писав що

Власний стартап — це не про гроші.
і мав на увазі те що написано після цієї фрази, чувак.
робити власний бізнес
Робота у ролі СТО в стартапі
вот эта фраза больше подходит для названия. Какая уж там карьера?
пройти весь шлях розробки продукту
это можно и совсем не в стартапе...
перетворити своє вміння програмувати на бізнес
а это — да, в стартапе. Да просто в бизнесе. И тут надо гораздо меньше програмирен, а больше маркетинга и продаж. Новые знания и навыки.
Але потрібно насамперед роботи мінімальний аналіз cost/benefit зі сторони бізнесу.
а также учитывать business requirements, business impact, обновлять P&L, risks и т.п.

знайшов ще одну статтю на ДОУ, майже дворічної давності... може кому цікаво...
dou.ua/...ta/articles/cto-position

а в цілому, побільше б таких статтей, бо про Junior Java Dev. вже напевно все чули)))

про Junior Java Dev
Зуб даю, что будет больше про Джуниор Жаба Скрипт Дев и Джуниор Малпинг Кюа.
На початку проекту часто виникає дискусія: чи почати писати проект на тому, на чому вмієш, чи взяти нову технологію. Перевагою першого варіанту, очевидно, є швидкість, проте другий варіант цікавіший з точки зору професійного розвитку.
Аналогично стоял выбор.
Я был волен в выборе языка. Надо было взять или Java (Spring Boot) или Scala (Play / Akka HTTP). Выбрал Java, так как и кода в сети больше и моего опыта.
.
На початковому етапі основна задача — це зарелізити MVP. Тут порада проста: швидко писати хороший код і ефективно вести комунікацію з колегами, які займаються бізнесовою частиною проекту.
Аналогично.
Приходится с огромной скоростью писать и при этом качественно (через 3 месяца к серверу постоянно подключены 10к пользоваителей через связку WebSockets/SockJS/STOMP, через 6 месяцев — 100к пользователей).
.
Також на ранніх етапах рекомендую звернути увагу на схему бази даних і регулярно говорити з колегами, які писали продукти, схожі на ваш. Погано підібрана схема даних означає необхідність міграцій даних і схем в майбутньому, а це далеко не найприємніший момент.
Как раз завтра буду поить чаем специалиста по Cassandra в попытке получить у него ответ на вопрос — как же разложить наши данные, например, в Cassandra. И надо еще найти специалиста “на поговорить” по масштабированию реляционных решений.
.
Дискусія допускається в пунктах про тести і документацію. Слід розуміти, що стартапи — це швидкість, і написання тестів може суттєво збільшити час розробки продукту.
+100500
Я люблю TDD, но совершенно нет времени.
.
На мою думку, основна мотивація хорошої команди програмістів — це складні і цікаві задачі. Мотивація повинна бути підтримана адекватною зарплатою, проте вона може і повинна бути нижчою за медіану по ринку.
Тут у меня немного другая ситуация.
1. Я не CTO, а TechLead, просто потому, что на пределами JVM я не силен. А CTO у нас как бы и нет пока.
2. С другой стороны у нас уже есть финансирование и сразу платят очень даже ничего. Т.е. не стоял перед выбором “жирный оутсорс” или “тощий стартап”. Правда я и не соучредитель, мне могут только stock option перепасть, если они когда-то планируются.

Большое спасибо за то, что делитесь опытом.
Я сейчас техлид в совсем свежем стартапе и многие из Ваших идей крайне интересны и полезны.

коли вам приходитимуть оффери з зарплатою на порядок вищою поточної
Будучи инженером, не могу не заметить, что «порядок» в десятичногй системе счисления — это 10.
Полагаю, что речь идет про разницу в 3-4 раза, т.е. «пол-порядка» (квадратный корень из 10, мы же на логарифмической шкале).

Ви переоцінюєте те які бувають зарплати у СТО на почтакових стадіях проекту без зовнішнього фінансування, і недооцінюєте оффери для хорших спеціалістів)

Давайте предположим, что на рынке предлагают 4к$.
В стартапе врядли речь идет про 300$-400$, скорее все же про 1к$.
.
Вопрос конечно про месяц от начала проекта на котором мы делаем замер. Понятно, что первые 3 месяца можно делать и на "подкожном жире"/энтузиазме.
.
Хотя, может и 400$ ... У нас просто есть финансирование.

А, это же я самому автору ответил про его же зарплату!
Конечно Вы лучше знаете:)
Мои извинения за невнимательность.

Все Ок) Ми також мали фінансування але коли воно закінчилося, а власне доходу від бізнесу ще не було то бувало і поменше ніж 300$ — тут немає чого приховувати. В такі періоди сам дуже добре розбираєшся в чому твоя мотивація.

У меня был совсем свой бизнес (я единственный владелец) — курсы программирования. Когда деньги закончились, я понял, что
1. преподавание я конечно люблю
2. но не до такой степени
3. бизнес (реклама, стратегии, клиенты) — совсем не мое. Просто неинтересно.

Пользуюсь вашим сервисом. У вас там две с половиной формы — зачем вам несколько программистов?

Дякую, що користуєтеся. Є багато речей «під капотом», які не очевидні для користувачів. Наприклад, прийом платежів з різних регіонів у різних валютах і автоматичний вивід коштів репетиторам. Під це все є функціонал який робить accounting і звірки. Звучить просто, але коли оброляти безліч кейсів таких як зміни ціни з сторони репетитора, скидки, реферальні ссилки, різні тривалості уроків, різні валюти в студента репетитора, різні таймзони, рефанди, неявки на уроки ітд — то все, на жаль, виходить складніше ніж просто обробляти форми. Алгоритмічно, є навіть machine learning(habrahabr.ru/...mpany/preply/blog/216729) і зараз змінили алгоритм ранжування, який математично максмізує client satisfaction метрику(там досить багато простої математики напр. нерівності Чебишева і класики по обрахуванню різних кореляцій, дисперсій і очікувань). Архітектурно у нас також трохи все складніше ніж сервер/база/кеш в силу того що ми ростемо по траффіку і багато асинхронності(використовуємо RabbitMq+Celery). Плюс локалізації на різні ринки що також не завжди буває просто з коробки.

То все таке, шо було сказано, а форм всього дві :)

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

Ну владелец одной из крупных контор (у вас она тоже представлена) совсем не гнушается кодить, причем кодит круто (на уровне Майерса). А в определенных кругах он очень известен и как дока в финансах. И да, он американец.

Або коли СТО єдиний програміст в команді)
тогда и команды разработчиков нет по определению.
Плюс бизнес импакт.

в команді стартапа малось на увазі

Трохи доповню.
Оскільки 99% так ніколи і не «стрельнуть», то на етапі МVP — важлива тільки швидкість реалізації, крім випадку коли сама технологія є предметом продажу. Все інше абсолютно не має ніякого значення.

закономірно постане питання можливості витримувати навантаження, що збільшуються
Це знадобиться тільки 1% з тих 1%, хто виживе.
Також на ранніх етапах рекомендую звернути увагу на схему бази даних
Я рекомендую на ранніх етапах взагалі не використовувати бази данних, а тримати все в RAM і скидувати на диск в разі потреби. Поки стартап виросте хоча б до 100к користувачів в БД немає сенсу. Плюси очевидні — ніякої міграції, не треба завязуватись на схему, яка на ранніх етапах міняєтсья кожен день, легше розгортати деплоймент.

+1
а SQLite отличный промежуточный вариант 8-)

Однопользовательская embedded—база на сервере? Думаю, Леопольд фон Захер Мазох, будь он жив, по достоинству оценил бы такое решение.

Я рекомендую на ранніх етапах взагалі не використовувати бази данних, а тримати все в RAM і скидувати на диск в разі потреби. Поки стартап виросте хоча б до 100к користувачів в БД немає сенсу.
Я б не ризикнув при 100К користувачів(і навіть при 10К) тримати все в RAM. Це я як людина в якої два рази за три роки крашилися в хлам продакшн сервери на Амазоні зауважую) Важко розумію які плюси в RAM чи SQLLite перед AmazonRDS.

Не розумію як креш амазона повязаний з тим що я написав.

Важко розумію які плюси в RAM чи SQLLite перед AmazonRDS.
Really? Як людина в якої за 7м місяців прода при лоаді 700 рек-сек і не було жодного факапа:
1) Амазон дорогий. Якщо в вас є купа лишніх грошей, Ваше право, але зазвичай це не про стартапи;
2) БД — це додатковий час на розробку;
3) БД — це додатковий час на деплоймент;
4) БД — це постійна підтримка табличок, схеми;

При малій кількості користувачів це просто оверхед і оверінжинірінг.

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

1. У Амазона є програми для стартапів де можна все юзати безплатно
2-4 Згідний, але у статті питання навантажень згадувалось на етапу росту і тоді без нормальної БД буде складніше.

При малій кількості користувачів це просто оверхед і оверінжинірінг.
100K(і навіть 10К) користувачів це, на мою думку, не мала кількість.
Якщо постійно писати на диск то по факту легше користуватися класичною базою на окремій машині.

Я б сказав навпаки =).

У Амазона є програми для стартапів де можна все юзати безплатно

Ну але далі Вам же потрібно буде масштабуватись. Є клауди в 1.5 рази дешевше (DO наприклад). Навіщо переплачувати за інфраструктуру 50%?

100K(і навіть 10К) користувачів це, на мою думку, не мала кількість.

Ну залежить від проекту. В мене 30к зараз, наприклад і це як на мене дуже мало. Вся моя база з репортінгом це цілих 100мб =). Прийдеться тепер написати статтю про це.

Ну залежить від проекту. В мене 30к зараз, наприклад і це як на мене дуже мало. Вся моя база з репортінгом це цілих 100мб =). Прийдеться тепер написати статтю про це.
Если у Вас из персистентных данных только список юзеров — хранить его можно где-угодно. Но при таком масштабе проекта вообще речи не должно идти, как будет быстрее вести разработку. Да пофиг как по-сути. И под репортинг база не нужна, можно всё считать на лету.

Если в потенциально серьёзном проекте, завязанном на серьёзный объём данных, изначально навелосипедить, то в большинстве клинических случаев, которые я встречал, к моменту выхода MVP в прод все велосипеды остаются на месте, т.к. менеджмент не даёт добро на переписывание по-человечески ибо “и так всё работает!©”. И через год — здравствуйте велосипеды на костылях. Ещё через два — здравствуйте конкуренты, которые сделали тоже самое, но они уже знали что идея рабочая, можно не заморачиваться mvp и сразу фигачить нормальный проект руками доблестных украинских аутсорсеров.

Є клауди в 1.5 рази дешевше (DO наприклад). Навіщо переплачувати за інфраструктуру 50%?
Потому что помимо ec2, у Амазона есть ещё три десятка разнообразных сервисов, из которых можно очень быстро не заморачиваясь инфраструктурными и архитектурными проблемами слепить вполне себе масштабируемый проект. Если, конечно, понимать как это делать конкретно на Амазоне, а не юзать его как банальную виртуалку.
Но при таком масштабе проекта вообще речи не должно идти
Каком таком масштабе? Когда разрабатывается MVP — у него нету пользователей вообще.
Если в потенциально серьёзном проекте
Хехе, как Вы интересно потенциальную серьезность проекта определяете =)? Речь про стартапы. Никто не знает что будет после MVP — смерть и бурный рост — лишь 2 крайности.
т.к. менеджмент не даёт добро
Это аутсорсное мышление. В стартапах нету менеджмента. Вы принимаете решение сами. Об этом статья.
Амазона есть ещё три десятка разнообразных сервисов
Которые тоже дорогие. Да и нужны не всем. Если что я плотно работал с амазоном 3 года, потому я его и не люблю. Я описывал продукт который мы делалил тут — dou.ua/...lenta/articles/11k-req-s
Каком таком масштабе? Когда разрабатывается MVP — у него нету пользователей вообще.
Да ну причём тут пользователи? Изначальный посыл был в том, чтобы вообще БД не использовать. Который я и ставлю под сомнение. Повторюсь. Если в проекте БД второстепенна и выполняет какие-то сервисные функции — это один расклад. Если БД является центральным компонентом и от правильности её выбора зависит будущее проекта или в принципе реализуемость идей, то другой. Нельзя же все стартапам безапелляционно рекомендовать «нахер бд» :)
Хехе, как Вы интересно потенциальную серьезность проекта определяете =)?
В данном контексте — уровнем вовлечения базы данных в архитектуру проекта.
Это аутсорсное мышление.
Видимо, с моим мышлением мне пора идти работать в аутсорс... )))
В стартапах нету менеджмента. Вы принимаете решение сами. Об этом статья.
Это в идеальном мире. В реальном никогда не хватает на всё ресурсов и начинается «приоритезация тасков». А кто принимает решение — это уже второй вопрос.
Если что я плотно работал с амазоном 3 года, потому я его и не люблю. Я описывал продукт который мы делалил тут — dou.ua/...lenta/articles/11k-req-s
Я отлично помню эту статью и мне вдвойне удивительно читать от её автора, что БД для стартапов — это лишнее.
Да ну причём тут пользователи?

При том что они потребители Вашего продукта.

Изначальный посыл был в том, чтобы вообще БД не использовать.

Именно. Для >90% стартапов это оверхед (мои слова основаны на проектах которые я регулярно вижу на SCT, на техкранче, стартап битвах и других стартаперских тусах).

и от правильности её выбора зависит будущее проекта или в принципе реализуемость идей

Заблуждение. Только ~15% стартапов умирают по техническим причинам. То есть выбор БД это максимум 15% влияния на конечный результат =).

Это в идеальном мире.
Нет. Это в реальности. Речь о CTO и он и принимает решения.

Нет, ну когда в ход идут проценты, мне тут крыть нечем... :) Если 90% стартапов не должны юзать БД, то там тому и быть.

Так, а кто мешает базе выделить кучу памяти? На чтение это будет полностью in-memory хранилище. Ну и как бонус — это абсолютно стандартное и знакомое всем решение с базой, а не свой хитрый велосипед.

Так, а кто мешает базе выделить кучу памяти?

Вопрос не в быстродействии. Вопрос в скорости разработки. И БД тут проигрывает. Поэтому на начальном этапе проекта, тем более когда это MVP в БД нету смысла. Это конечно же только мое имхо, основанное на собственном опыте.

а не свой хитрый велосипед.

Так нету никаких велосипедов. Вы просто работаете с объектами и все. Если надо делаете Files.saveToFile(data). Все =).

Иногда персистентность просто необходима. Например, хеши паролей при регистрации. Как авторизировать потом пользователя, если данные лежат в RAM?
Плюс современные ORM делают всю работу со схемой, миграциями и транзакциями за вас. Вы все так же работаете с объектами, а какой-нибудь Observer сделает за вас всю грязную работу. Развернуть mysql / postgres / mongodb в любом облаке — дело 10 минут и 15 строк конфига какого-нибудь паппета.
Прокомментируйте, пожалуйста, что конкретно имеете в виду под работой с объектами. Спасибо.

с моей колокольни: иногда необходима, а иногда лишний головняк — при том что это _прототип_ и его цель просто показать что какая-то проблема может быть решена вот так. Конечно никто не говорит о том что храним только в RAM и любой рестарт аппы и все капут ))

Подход in-memory в данном случае означает, что все структуры мы удобно и красиво храним в коллекциях и хеш-таблицах. Не морочимся никакими индексами и прочим — так как все в памяти, все просто летает (важно для демо и проверки гипотезы), а код простой и незатейливый. При изменении данных, просто сбрасываем состояние — банально в файл(ы) или как вариант SQLite (причем забываем про всякие нф, если проще сериализнуть связанный объект\коллекцию в json — так и делаем), а при запуске обратно вычитываем. Конечно можно сразу заюзать какую нибудь монгу, редиску или полноценную БД. Но зачем?? Зачем что-то разворачивать, а потом при изменениях мигрировать и т.д.? Это стандартная проф деформация занятых в аутсорсинге — привыкли что проект это то что надо сделать и ним будут пользоваться. Да неясно еще что сделать, как сделать, кто будет и сколько будет. Чем проще — тем лучше.
Как только прояснится что к чему — можно уже будет выбрать что использовать исходя из реальных потребностей, а не «думать наперед» (и в 99% этот выбор будет мимо).

Дмитрий, поправь если ты имел ввиду что-то другое )

Прям идеальное изложение моих мыслей!

то стандартная проф деформация занятых в аутсорсинге

В точку! =)

Иногда персистентность просто необходима.
і скидувати на диск в разі потреби.
Плюс современные ORM делают всю работу со схемой, миграциями и транзакциями за вас.
И привносят пачку своих собственных проблем.
Прокомментируйте, пожалуйста, что конкретно имеете в виду под работой с объектами. Спасибо.
Если Вам действительно интересно, весь код тут — github.com/blynkkk/blynk-server. Как я сказал выше, я напишу об этом статью.

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

Мои аргументы:

1. Трафик стартапов растет не линейно, а скачкообразно. Попадание на «главную» Хабра, DOU или Product Hunt может увеличить количество запросов на несколько порядков.
Если база данных хранится в памяти и только периодически сбрасывается на диск, то приложение, очевидно, не являтся stateless и не может быть легко горизонтально масштабировано.
Вертикальное масштабирование сервера требует, как минимум, перезагрузки и во время пиковой посещаемости крайне нежелательно. И то, это возможно, если апп не хостится на bare metal сервер, а использует облако.
Этого, собственно, уже достаточно, чтобы не использовать память-жесткий диск. Стартап всегда должен быть готов к пиковым нагрузкам.

2. MVP обязательно предполагает наличие пользователей. В этом и есть суть MVP: протестировать value proposition и получить фидбек от реальных юзеров. Проверка возможности реализации технического концепта называется «proof of concept» и для большинства стартапов является тривиальной задачей.

3. Большинство MVP разрабатываются на динамических ЯП с использованием популярных MVC фреймворков: Rails, Django, Phoenix, различные варианты для nodejs. Создание датастора без базы данных увеличивает время разработки, а не сокращает его. Интеграция с базами данных в таких фреймвоках предоставляется «for free».

4. Валидация данных. Вместо того, чтобы использовать стандартную валидацию типов данных в SQL базах данных придется писать собственные хелпер функции. Вместо протестированного годами и миллионами деплойментов кода, за data integrity будет отвечать самописный велосипед. Где тут выигрыш?

5. Логично, что на этапе быстрой итерации постоянно менять схему данных неудобно. И для этого сценария существует формат jsonb для PG или RethinkDB, если хочется nosql и кластер. Подойдет даже Mongodb.

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

7. «Именно. Для >90% стартапов это[база данных] оверхед». Кто там говорил о профессиональной деформации?

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

Исходя из пунктов 1-8, считаю, что для подавляющего большинства стартапов и бутстрэпов оптимальным решением является использование PostgreSQL. До тех пор, пока эмпирически не доказано обратное.

Трафик стартапов растет не линейно, а скачкообразно.
Стартап это обычный бизнес, который растет вполне себе линейно. Достаточно почитать истории восхождения известных проектов.
Попадание на «главную» Хабра, DOU или Product Hunt может увеличить количество запросов на несколько порядков.
Очень плохой пример. Публикация на главной хабра дает целый 1 рек-сек на протяжении нескольких десятков минут об этом есть даже статья на хабре =). Product Hunt дал моему знакому целых 5к скачек за день на платформу за Featured Day App или как там оно называется. Конечно, если писать системы на всяких хипстерских штуках вроде монги и ноды, то нагрузка в 1 рек-сек уже может считаться серьезной (известный хабра эффект). Но публикации в более известных изданиях, да, могут увеличить нагрузку на порядок.
только периодически сбрасывается на диск
Ну записывайте сразу. В чем проблема то?
и не может быть легко горизонтально масштабировано.
Глупость. Важна архитектура, разделение на слои, а что за инструмент сбрасывает данные на диск совершенно не важно будь то СУБД, No-Sql или обычный File.save.
Вертикальное масштабирование сервера требует, как минимум, перезагрузки и во время пиковой посещаемости крайне нежелательно.
Ну есть инструменты, что поддерживают hot-deploy, есть elastic IPs, да много чего есть.
Этого, собственно, уже достаточно, чтобы не использовать память-жесткий диск.
Как будто СУБД их не использует =).
придется писать собственные хелпер функции
Зачем? Я так понял речь об динамических языках? Ну тут может быть. Принимаю.
И для этого сценария существует формат jsonb для PG или RethinkDB, если хочется nosql и кластер. Подойдет даже Mongodb.
Правильно, о чем я и говорю. Зачем тут БД вообще?
Другие недостатки: отсутствие транзакий
Вот это реальный аргумент. Но так ли они нужны большинству? Сомневаюсь. Опять же, сужу по проектам что встречаю.
больше тестов
Меньше тестов.
в самописной технологии
Нету никаких самописных технологий. Вы о чем? Files.write уже самописная технология?
отсутствие тулинга для подключения к лайв базе данных.
Засчитываю.

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

Стартап это обычный бизнес, который растет вполне себе линейно.
Стартапы растут линейно? Ну-ну.
Но публикации в более изветных иданиях, да, могут увеличить нагрузку на порядок.
Ну-ну. Публикации в «более известных изданиях» и в соц.медиа как раз идут каскадом после попадания на HN/PH/reddit/DOU.
Глупость. Важна архитектура, разделение на слои, а что за инструмент сбрасывает данные на диск совершенно не важно будь то СУБД, No-Sql или обычный File.save.
Ну-ну^2.

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

Для >90% стартапов это[база данных] оверхед
Стартапы растут линейно? Ну-ну.
Да. Как бы Вам не хотелось верить в обратное. Вот например для фейса quumf.com/...1/12/Facebook-growth1.png. 4 года стабильного линейного роста. Потом ускорение. Но нужно понимать, что это самый топовый в мире ресурс. У остальных рост не такой веселый. В общем гугл вам в помощь.
Повторюсь, спорить я не собираюсь, мой комментарий направлен на читателей, которые вдруг могли принять на веру тезис
Я тоже. Поэтому Вам и отвечую, чтобы Вы не давали своих вредных (с моей точки зрения) советов.

Залежить з якого боку подивитися на ріст фейсбука — якщо так:
imgur.com/5c0lX01
то експонента :)
Я думаю, що ваше твердження про

Для >90% стартапов это[база данных] оверхед
надто сильне щоб учасники дискусії могли погодитися з ним. Проте інструментарій перевірки цього твердження надто складний(треба взяти вибірку стартапів, що починають заміряти хто без бази, і через 3 роки перевірити в якому сегменті більше успіху).

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

2. ... Проверка возможности реализации технического концепта называется «proof of concept» и для большинства стартапов является тривиальной задачей.
6. MVP превращается в рабочий продукт непредсказуемо для команды фаундеров. Когда приходит популярность, времени на переработку архитектуры просто нету.
Вы предсказуемо противоречите самому себе двумя собственными тезисами. Предсказуемо на основании реального опыта включая видимо ваш собственный который у вас обобщить и сопоставить 2 пункта друг с другом всё так же предсказуемо не получается.
До тех пор, пока эмпирически не доказано обратное.
Эмпирически доказано что на этапе MVP там встречается настолько что угодно что хватает работы на человеко-годы для «промышленной разработки аутсорсеров» куда обычно и передаются «гаражные наколенные поделки MVP» по факту выхода на IPO иногда на более ранних стадиях финансирования когда «успешных фаундеров» сменяют «успешные менеджеры» как одно из требований инвестора а «тривиальная задача технической реализации» выбрасывается из основного бизнеса который сосредотачивается на продажах и удовлетворении клиентов/пользователей (не следует путать первых и вторых). Но по сути в этом случае речь идёт не о том что можно называть «технологический стартап» сколь бы он ни был связан формально с некой технологией. Обычно это «ещё один облачный сервис для хранения с неограниченным простанством и шлюшками» или «ещё один сервис VPN со встроенным блекджеком» и технологическая составляющая там существует постольку поскольку. Чисто технологические компании даже если назвать их стартапами обычно покупаются целиком именно как технология и ни о каком «взрывном росте MVP» речи не идёт и ценность имеет именно та самая «тривиальная задача реализации „proof of concept“».

ЗЫ: а вспомнил название первого класса стартапов: «социальные сети для собак». (к) (тм)

В кожного свій досвід.... Був в мене проект без БД, все як ви пишите.... До цього часу плююсь, що не зробив там хоч якийсь SQLite.
А якщо щось серверне, то щось слабше за MySQL і розглядати не варто.
Структури в пам’яті — це круто, якщо проект дозволяє/потребує. Але все має свою ціну. І не кажіть, що у вас там дійсно один Files.write. Скинути складно зв’язну структуру з пам’яті на диск — це окрема задача і тона коду. А якщо ще щось перерветься в процесі запису? То ще й доведеться напівзаписані дані розгрібіати або миритися з втратами.

Плюси очевидні — ніякої міграції,
Ну да, що там... DROP DATABASE + CREATE DATABASE :)
не треба завязуватись на схему
Особливо в самописаних файлах. Давно ви писали окремі методи, щоб вичитати в пам’ять дані з старого файла? Вот вже років 8 пройшло, а я ще пам’ятаю як я робив це.

Вот чесно ... в стартапі немає проблеми прямо на живій базі додати табличку/колонку.
Проблемою це стає пізніше. На моєму досвіді, нюанси з міграціями виникали лише тоді, коли робочих баз з однаковими схемами стало 4:)

З іншої сторони... якщо у вас дійсно 700 запитів в секунду, то вам дісно варто працювати з пам’яттю. Але всі дані, що потребують бути persistent краще все-рівно в базу, потім на репліку і потім в бекап.

Кожен проект різний ... подумайте як ви без бази стартанете щось аля fb чи ebay. Та навіть DOU без бази у вас перетвориться в вермішель.

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

А якщо щось серверне, то щось слабше за MySQL і розглядати не варто.
Ну якщо Ви так авторитетно заявляєте, то як тут не погодитись.
І не кажіть, що у вас там дійсно один Files.write.
github.com/.../dao/FileManager.java#L76
А якщо ще щось перерветься в процесі запису?
Це саме відноситься і до БД.
Ну да, що там... DROP DATABASE + CREATE DATABASE :)
?
Давно ви писали окремі методи, щоб вичитати в пам’ять дані з старого файла?
Тільки коли писав декодер Jpeg. Але має підозру, що Ви мали на увазі щось інше.
Вот вже років 8 пройшло, а я ще пам’ятаю як я робив це.
ВІдчуваю біль =).
Вот чесно ... в стартапі немає проблеми прямо на живій базі додати табличку/колонку.
=))) ну я це даже коментити не буду.
Але всі дані, що потребують бути persistent краще все-рівно в базу, потім на репліку і потім в бекап.
А як на рахунок в файл, а потім в бекап?
ви або геніальний троль
Ні. Я темний ельф 80-го левела.
github.com/.../dao/FileManager.java#L76
А тепер уявіть, що User.name треба переіменувати на login і додати поля firstName та lastName.
Ваші дії?
А якщо ще щось перерветься в процесі запису?
Це саме відноситься і до БД.
Я, напевно, десть пропустив в вашому коді логи транзакцій.
Ну да, що там... DROP DATABASE + CREATE DATABASE :)
?
Я про те, що від міграцій даних ви нікуди не дінетесь.
І у вас і з БД можна допроектуватися до того, що потім різати по живому доведеться.
Ваші дії?
Добавляю login. При лоаді файлів копіюю нейм в логін. Все. 2 строчки коду.
транзакцій.
Для чого?
Я про те, що від міграцій даних ви нікуди не дінетесь.
Робиться на порядок простіше ніж з БД.
І у вас і з БД можна допроектуватися до того, що потім різати по живому доведеться.
Ну слухайте, якщо руки криві, то інструмент і підхід вже не має значення.
Добавляю login. При лоаді файлів копіюю нейм в логін. Все. 2 строчки коду.
При цьому 1) name видалити ви не можете зразу. 2) пишите код для міграції
Для чого?
Ви ж казали, що проблеми з записом на диск відносяться і до БД. Але там це питання вирішується за допомогою логів транзакцій. У вас ж рішення відсутнє.
Робиться на порядок простіше ніж з БД.
Як кажуть на смак та колір фломастери різні.
У вас ж рішення відсутнє.

Так, тому що мені це не потрібно. Це ж одна з фішок стартапів. Я чудово розумію бізнес складову проекту, я знаю, що важливо для користувачів в першу чергу і знаю, що для них абсолютно не має значення.

не використовувати бази данних, а тримати все в RAM
В чем преимущество собственного квадратного колеса перед Redis, в данном конкретном раскладе? Схемы нет, данные в RAM, быстр, вся вспомогательная обвязка уже написана.

PS. Да, порой встречаются очень хитрые предметные области, под которыe не подходит ни одно общедоступное решение, и без своей подсистемы storage не обойтись. Но разве Blynk из таких случаев?

В чем преимущество собственного квадратного колеса перед Redis

Отвечу Вам цитатой одного европейского CTO:

Rather than making my app easy to deploy, I’ll just do a bunch of gnarly shit in Docker
и без своей подсистемы storage не обойтись
Нету никакой подсистемы storage. Пруф — github.com/...rver/dao/FileManager.java кода немного много получилось, но это только потому что я решил попробовать новое Java API.
Rather than making my app easy to deploy, I’ll just do a bunch of gnarly shit in Docker
Суперхитовый полемический прием ’rеductio ad absurdum’. Позволяет спорить до бесконечности. Вот только смысл результата такого спора ускользает. Так что, предлагаю вспомнить древнюю поговорку «все есть яд, и все есть лекарство», и прекратить обвинять БД и системы автодеплоймента.
Пруф
Ок, что я вижу в пруфе? Вижу сериализацию/десериализацию пользователей, каждого на уникальный файл. При таком простецком сценарии соглашусь: и БД как атомная бомба по воробьям, и о каком-либо кастомном storage даже говорить смешно, настолько всё по пояс деревянно :) Но не всегда и не у всех дела обстоят так, даже в MVP.

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

вигрузка всіх сирих даних в спеціальні програми бізнес-аналітики.

А можете привести примеры таких программ? Я или плохо искал, или не нашел те (web-based), которые могу адекватно работать (выгрузка по API) с самой разной информацией, связанной и нет, делать выборки и подсчеты, строить графики по ним и прочее.
Буду очень благодарен за подсказки.

UPD Поздно увидел ответ вот тут dou.ua/...icles/startup-cto/#807614

Потрібно розуміти, що робота в стартапі — це не про гроші (принаймні в перші роки). Якщо основна мотивація — заробити кошти, то набагато легше піти в аутсорс або емігрувати.

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

Хіба що ви самі з колегами починаєте стартап на зекономлені гроші.

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

А я хотів зауважити що такий висновок не правдивий для всіх компаній. Принаймні моя компанія яка теж є повноцінним стартапом (на правах реклами :))

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

Автор мав на увазі що у ролі СТО чи СЕО відразу не заробиш мільйони. Але звичайні наймані працівники таки повинні вибивати собі ринкові зарплати ;)

Або просити опціони, що на жаль менш популярно.

З того що чув, опціони у наших реаліях — це як вилами по воді писано. Тому краще просто просити ринкову зп +х% :)

З того що чув, опціони у наших реаліях — це як вилами по воді писано.
It depends. В частині «Бізнес» статті розповів своє бачення. Знаю історії успіху коли опціони працювали для українських компаній. Просити ринкову зп+% — це право того хто шукає роботу. Примати рішення чи варто працювати з такою людиною — право СТО. Якщо людина зациклена, що її зп має бути «ринковою» і просить % — то для мене це був би red flag.

Я інше мав на увазі. Просити наприклад 110% середньоринкової зп. Робота у стартапі як не як це деякий стрес через то, що він може накритись. Тому якась надбавка буде чесно.

Але то таке, дискусія трошки не в то русло пішла. Топік то про кар*єру СТО, а не про гроші :)

Резонно. Проте окрім стрессу у деяких стартапах є й драйв якого немає в інших компаніях тому цілком резонно інколи пропонувати 90%.
Загалом, ви праві про те що ми відхилились, це про карєру, а не про гроші)

Цікаво а коли люди працюють в аутсорсі — в них нема стресу що кастомер забере проект, їх посадять на бенч і звільнять?

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

Правильні опціони підкріплюются контрактом для людини яка їх отримує.

Я пишу про карєру СТО, і все таки наполягаю на думці, що якщо ціль СТО заробити гроші — то є легші способи ніж стартап. Якщо ви шукаєте СТО і всі кажуть, що це не стабільно/не платять/ітд — то я б не рекомендував працювати з такими людьми — вони будуть поганими СТО в стартапі(але можуть бути прекрасними СТО в аутсорс компаніях, або у стартапах які вже бізнеси).

Я б ще додав — що якщо ви шукаєте роботу СТО, то найти аутсорсну компанію для такої посади буде не проста задача. Особливо якщо за плечима немає декількох стартапів/компаній де ви виконували цю роль.

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

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

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

Ну якщо навіть лоторейні білети не купляти — то точно нічого не отримаєш.

А как насчет развиваться и работать, например? Уже не котируется?

Робота в стартапі не заважає, а навіть підштовхує розвиватись і працювати.

Я навіть більше скажу, навчання і активна робота кожного конкретного працівника збільшить шанси що стартап не загнется.

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

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

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

Узнать всего по чуть-чуть? Добро пожаловать в любой средней руки боди шоп, они почти без исключений предоставят все эти скилы (за исключением, пожалуй, end user support).

В бодишопе мало возможностей взять язык с потолка из принципа «хочу его выучить», и СТО не желает рисковать срывом сроков после таких решений? Фриланс в одном клике. Нет возможности выбрать язык за заказчика — но есть возможность выбрать заказчика с пожеланием нужного языка (или без предпочтений). И, опять же, любой комплиментарный набор от гугл аппс до облаков.

В стартапы у нас не хотят идти потому, что те стартапы что пихают на рынке в массе своей не могут предложить чего-то конкурентноспособного. Доля в компании в наших реалиях — пшик, даже если не учитывать что 90% этих предложений — банальный лохотрон.

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

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

І до останнього параграфу: 90% людей які кажуть що стартапи це пшик і пусті обіцянки — ніколи не працювали в стартапі.

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

Возвращаясь к теме обсуждения,

заробити великі гроші
в стартапе с выживаемостью оных (возьмем оптимистично) 10% можно. С тем же успехом можно не играть в лотерею, а заниматься интересными вещами, и повышать свою ценность, как специалиста, и иметь намного меньший риск и больший профит в среднем, плюс намного больше интересных задач. А уж заработанное можно и в лотерейные билеты вкладывать, и в опционы, и куда душе угодно. Это больше вопрос к темпераменту человека, кто-то любит стабильный кусок хлеба, кто-то играет “на все”.

Есть “цивилизованные” стартапы, есть “дикие”. На наш рынок первые выходят намного реже, особенно в поисках CTO. И да, я работал в стартапе на аутстаффе — без доли в компании, зато с полной свободой выбирать инструменты и архитектуру для решения задач.

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

Вони і далі кажуть «не вєрю». І далі повторюють: Ви ж не стабільні. А от аутсорс компанія N з 20/100/1000 людей не зможе звільнити мене або прогоріти, або не витримати кризи. Вона ж стабільна!!!

Мені от цікаво, відколи програмісти почали боятись знайти нову роботу? Я думав будь хто міддл левел або вище, з акаунтому в лінкедін отримує мінімум декілька пропозицій на місяць про нову роботу.

Скільки ти людям не кажи що ти платиш ті ж самі гроші,
Зачем переходить на те же деньги?
даєш ті ж самі цікаві задачі
верстать лендинг? тестировать на продакшене? настраивать мейл-сервер?
свободу вибору/розвитку/навчання та опціони
Пренебречь качеством архитектуры, игнорировать технический долг, экономить на тестах, писать слабо документированные фичи.
верстать лендинг? тестировать на продакшене? настраивать мейл-сервер?
Пренебречь качеством архитектуры, игнорировать технический долг, экономить на тестах, писать слабо документированные фичи.

7.times {'ні'}

Зважди набір стереотипів.

А тепер задайте всі ці питання собі. Чи сусідам на інших проектах. Скільки разів ви зможете сказати ні?

Да прям таки стереотипы. Если мы говорим о начальной стадии, где в команде 1 программист/СТО, то все технические задачи пойдут на него, начиная от регистрации домена, заканчивая деплойментом и смоук тестами.
А насчет технического качества — знаете, чем отличается архитектура стартапа с основателем-программистом от стартапа, где программисты сидят на рыночной зарплате? В первом случае выходит очень жесткая каркасная архитектура, выполняющая только те задачи, которые входят в MVP, вплоть до хардкода и упрощения бизнес-логики в угоду простоте и скорости разработки. А во втором — получается гибкое нечто, усиленное свободой выбора и непониманием, с какой ноги встанет завтра СЕО и какую кнопку попросит передвинуть. Так и появляются велосипеды, этажи абстракций и универсальных решений, которые через полгода будут переписывать с нуля.
Вот поэтому программисты и хотят писать пет-проекты дома (которые они в большинстве случаев и не запустят никогда, зато доведут до совершенства) и ковырять 8 часов говно-xml на работе, чем сидеть на зарплате по 12 часов у подобных романтиков-основателей, которые не понимая значения «технический долг» и «рефакторинг», мечутся из стороны в сторону и соблазняют опционами в стране, где «маски-шоу» происходит по нечетным числам.

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

В аутсорсі таких проектів не менше в відносному. І ті ж самі проблеми з «технічним боргом», «рефакторінгом», «костилями» та «овертаймом».

Всі говорять про проблеми стартапів — але ніхто не хоче прийти і їх вирішити (якщо вони є).
Всі говорять про проблеми стартапів — але ніхто не вирішує ті проблеми в свому теплому ламовому аутсорсі.

Особливо дико звучать звинувачування в якості продукту коли люди з аутсорсу:
— в 90% випадків не пишуть тести
— 75% людей не знає що таке рефакторінг
— 90% людей не може продумати архітекуру на 5 класів.

Це все живі результати співбесід. Статистика працівників з продакт компаній і стартапів — трішки ліпша.

Знову ж таки переадресую запитання вам. Який відсоток проектів у вашій компанії не мають проблем які ви перерахували для стартапів?

В Сиклуме сотни проектов, я не имею полной картины по всем. Одна из моих задач — продавать клиентам рефакторинг, тесты, архитектуру и инженерные практики. Сейчас все эти активности входят в эстимацию проекта (если мы не говорим про аутстаф-модель), чего несколько лет назад не было и в помине.
А касательно овертайма — я не знаю ни одного случая, когда овертайм не был оплачен (не говоря уже о х2 рейте). В аутсорсе программисты церемониться не будут — покажут контракт с рабочими часами, встанут в 6 и пойдут домой. В стартапе такие траты попросту невозможны.
Многие инкубаторы дают до 50К посевных. Это год рыночной зарплаты 1 программиста в Украине. Экономия будет тупо на всем, на чем только можно сэкономить.
Я решаю проблемы стартапов очень просто — пишу свой проект как хочу и когда хочу.

Но, простите, при чем здесь это? Мы ведь говорим о заработке огромных денег, мульонов, лежащих в стартапах. Которых десятками тысяч каждый год появляется. Вот я и пытаюсь выяснить, какова эта выгода, и почему вокруг продвинутые СТО не разъезжают стадами на бентли. По поводу задач мы ведь уже выяснили, что они не лучше и не качественнее, чем где-либо еще, не далее чем постом выше.

Я про ті ж самі заробітки мільйонів.

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

Так будем відверті, ризик є. В стартапі більший, в Аутсорсі, можливо, менший. Але так само є ризик що вас зібє автобус і нічого вже не треба буде.

Якщо відкинути страх пошуку нової роботи, відсутність упереджень по обовязках і можливостях розвитку все зводится до того що:
— В аутсорсі ви заробите свої N*10000$ на місяць і більше нічого
— В стартапі ви заробите свої N*10000$ на місяць, і 10% шанс (з вашої статистики) «мільйони»

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

Під «мільйонами» маются на увазі гроші в кілька разів більші за річну зарплату (все залежить від успішності стартапу)

Чому CTO мають хотіти роз’їзджати на бентлі, та ще і стадами?

А как насчет развиваться и работать, например? Уже не котируется?

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

Заробити мільони і мати мотивацію заробити мільйони це різні речі. Я не проти заробити мільони, але моя мотивація не в цьому.

Дякую за статтю, цікавий досвід.


— Статистика. Помилка, яку часто допускають в стартапах — спроба писати внутрішню систему статистики (ми також цим хворіли). Це дуже неефективне використання ресурсів, адже практично неможливо передбачити всі метрики/розрізи. Рішення — вигрузка всіх сирих даних в спеціальні програми бізнес-аналітики.

Можете навести приклад того, що Ви використовували і Вас задовольнило?

Сопчатку пробували аналізувати данні в kissmetrics, google analytics з enchanced ecommerce проте налаштування цих системи не дозволяє достатньої інтеграції з базою. Після цього пішли в сторону periscope.io — надто дорогі, цікава опція amplitude.com — але поки приглядаємося. Зараз зупинилися на інтеграції з excel+power pivot+dax. Поки все влаштовує хоча постійно покращуємо цей BI стек.

Я не автор, але лінк кину global.qlik.com/ru
використовували на проекті де багато даних

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