×

Кого искать в развивающийся стартап?

Добрый день! Помогите советом.
Наш стартап в сфере Веб (типа маркет-плейса в сфере услуг) изначально делался на Друпал 7. С помощью стандартных и, позже написанных под заказ, модулей. Это был наш MVP :)
Мы выжили, свою бизнес-модель обкатали, но со своим Друпалом упёрлись уже в потолок. Теперь надо всё переписать «по уму» и добавлять новые функции.
Здесь-то и случился полный ступор..
1. Не понятно с какой стороны к этому мероприятию подступится... Наверно нужен Техлид или PM?
2. Не понятно сколько денег и времени уйдет на только переписать текущий функционал, а надо еще внедрять новый. То есть, надо определится сколько искать денег, каких специалистов, на каких технологиях разрабатывать.
3. Офис находится в Одессе. Искать офлайн спецов или удаленных?
4. Есть мнение, что из-за того что главный основатель — женщина, это тоже может вызвать некоторые проблемы. Это так? :)

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Хочу сказать сообществу «Большое спасибо»! Очень помогли, комментариями и личным общением, поставить мозги на место.
А именно решила:
1. Сначала навести порядок в текущем проекте. Без всякого переписывания сайта. По крайней мере не сейчас. Научится и организовать документирование в проекте, и тестирование. А, так как мне некогда еще и этим заниматься, значит...
2. нужно открыть вакансию СТО или Product Manager-а. По-прежнему, правда, не понимаю как их ищут и выбирают :) Рядового сотрудника нанять проблемно, но тех хотя бы можно взять и обучить, или перебирать пока не подойдет))
3. По поводу поиска инвестиций, тоже подуспокоилась. Такие глобальные движения ради новых функций — не самая умная идея. Еще можно подумать об этом, если есть желание выходить на другие страны и организовывать там всё с нуля (платформу, представительство, персонал).

Впервые написала на этом форуме и получила массу ценной информации. Очень продуктивно) Спасибо)

нужно открыть вакансию СТО или Product Manager-а. По-прежнему, правда, не понимаю как их ищут и выбирают :)

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

Тому «стартапу» п′ять років, і він нормально себе чухає. До того ж він не технічний, а скоріше іноформаційний — тобто технічна частина не є унікальною, якихось ноу-хау там нема, а є звичайна собі бізнес-логіка.

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

За рахунок обмеження рикну Україною стартап вже витягнуто зі стадії стартапу. Але ще не вилизано до стадії легкої реплікації чи стрімкого росту. Той самий період, коли бізнесу варто спочатку подорослішати, а вже потім заводити дітей :)

Якщо коротко — це не стартап, це звичайний проект на внутрішньому ринку. З відповідними pros/cons. Тому і рекомендував не рипатися із серйозними інвестиціями — вони себе не окуплять доки процес не вийде на низькі видатки.

Вік стартапу не грає ніякої ролі. Перехід від стартапу до зрілої компанії відбувається за однією ознакою — появлення процесів. Це розділення зон відповідальності, ієрархія, легка заміна працівників на інших, прозорість та контрольованість всього бізнес-процесу та готовність до масштабування.

Когда количество менеджеров превышает количество гребцов

Менеджери бувають різними... Є клінінг-менеджери, є менеджери з продажу, є греблєменеджери.

Навпаки, саме вік має значення. Зрілість конфліктів. Коли вже не міряються пісюнами та не погрожують вбити фейсбук — то вже не стартап.

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

Зрілий стартап — то ж вже не стартап... Це просто нова компанія.

Кого искать в развивающийся стартап?

Дата саінтіста

Глупый вопрос: а вы уже перешли на PHP 7.1? Потому что это реальное ускорение по сравнению с 5.6. Он хоть и кушает больше памяти, но кеширует код, и за счёт этого всё летает. Для Друпала очень существенно — с его-то огромной последовательностью вызова кучи модулей и хуков.

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

Сам Друпал 7 на нём пашет удивительно быстро, поддерживаемые разрабочиками модули тоже.

Акцент: Если искать инвестора в подобный стартап — это может закончиться очень тяжёлым разрывом, со смертью проекта. Особенно если сам проект в юрисдикции Украины, то есть суд в принципе отсутствует как таковой и сводится к тому кто больше даст взятку.

Повторюсь, инвестирование — это очень дорого для того, кто инвестицию принимает. Если у вас нет CTO, сомневаюсь что у вас есть собственный юрист со специализацией по внутрикорпоративным вопросам в стране юрисдикции. Если в Украине — вам никакой юрист не поможет, здесь кидалово нормально и повсеместно. Здесь даже миллиардер не может быть уверен что его не кинут.

Инвестирование хорошо работает там, где оно хорошо работает. Где есть механизмы правовой защиты, вы уверены что они работают, и где эти механизмы имеют низкие издержки. То есть можно сосредоточиться на бизнесе, а не на правовых тяжбах. И там ОГРОМНАЯ КОНКУРЕНЦИЯ за дешёвые инвестиции. Потому НЕЛЬЗЯ выходить туда раньше времени — если взять дорогих инвестиций, наверняка будет банкротство, потому что инвестору интересна быстрая прибыль — и он убьёт клиентскую базу дурным спамом, что даст пик прибыли, и постоянный долгосрочный отток.

Хочу Вас порадовать всё не так уж и плохо)
Бизнес-ангелы существуют и они не страшные, просто не надо брать деньги на не внятных условиях. Нас проинвестировали, когда ещё не было практически ничего. Совсем допотопный сайтик на друпал 6, совершенно незнакомый человек с биржи стартапов.
Верьте в себя и будет вам счастье)

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

Что касается потолка не очень понятно — друпал просто набор классов на PHP — работать на нем конечно геморно но технически нет ничего во что можно упереться. Посему непонятна проблема.

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

Почему бы вам не дать ссылку на ваш сервис? Обсуждение было бы предметнее. Я иногда участвую в разного рода стартапах. Толку пока с них не было — но мое дело написать код.
И с женщинами кстати работать лучше — они как то ответственнее и порядочнее.

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

Монетизация есть. Проект вышел на прибыль ещё 3,5 года назад. А бесплатно никто никогда не работал)

Да и переписывать можно впаралель. а потом просто перегнать
данные

так и планирую.
Ссылку то дать можно, это не секрет. Просто не хочу, чтоб дальнейшее обсуждение уходило уже в русло обсуждения проекта, типа «О, Боже и на что вы здесь рассчитываете, обычный сайт, и т.д.».
Стукните в личку, дам ссылку.
Достаточно информации, что проект зарабатывает, инвестиции от бизнес-Ангела уже были (на самом старте) , и есть желание и потенциал сделать резкий рывок вперед.
Надо понять цену вопроса и какие могут проблемы с разработкой и разработчиками.

Стукнул

Добрый день. «Переписать» — это решение, а не цель. Пока не понятно решение чего. Самый успешный проект, который я видел, был страшен в коде как атомная война. Что не мешало ему приносить кучу денег своим владельцам.

Теперь по пунктам.
1. Для начала нужно понимать, что Вам нужно от проекта. Т.е. ТЗ в любом виде: документ, маинд-мап, сторимап, короче — как умеете. Крупными мазками. Вот после ТЗ — можно разговаривать о чем либо ещё. В противном случае, может так случиться, что проект то перепишут, а вот профита не будет. И да, мой опыт подсказывает, что переписывание проекта в стиле «вот вам рабочий сайт, сделайте такой же» — приводит к потере кучи функций.

2. Вот после пункта 1 можно будет подсчитать. Правда ещё возникнут вопросы временных рамок (аутсорс — быстрее, дороже. Инхаус — дольше, может быть дешевле).

3. Зависит от навыков человека, который будет управлять командой (т.е. который будет нести перед вами ответственность за тех. процесс). Если он умеет в распределенную команду — можно нанимать удаленно. Если не умеет — то только в офис.

4. Существуют люди, которые по каким-то причинам не могут работать под руководством женщины-руководителя. Но с моей точки зрения, это довольно редкая девиация.

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

При росте в 65% в год " всё переписать" — это очень дорогое решение. Потому что проект при этом переходит в альфа-версию, и можно просто завалить всё на технической части. Куда проще по опыту довести до ума существующие решения, получить ещё 65% на ровном месте, а может и ещё — и тогда уже переписывать правильно, имея для этого и время, и деньги. Главное деньги. Весь вопрос в деньгах — чтобы их НЕ ПОТЕРЯТЬ, а гарантированно сохранить прибыль.

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

Согласна. Это один из рассматриваемых вариантов. Из-за того что Друпал не сложная (как по мне) CMS, очень много откликов от школьников и непрофильных специалистов. Тяжело найти профи.

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

Люди в принципе плохо работают под руководством одного человека. Здесь вопрос о делегировании ключевых вопросов вниз. Единственный случай, когда с женщинами работать тяжело — если сильный гормональный дисбаланс (в возрасте), и женщина не корректирует его мед.препаратами. У мужчин такой кризис тоже есть — но он в подростковом возрасте, мало кто назначит подростка руководителем, и вам точно будет тяжело под ним работать.

Самые худшие руководители — верующие в какую-нибудь магию, просветление, тибетских божествов и тому подобные «позитивы». Решения, принятые на этой основе — убийственны, потому что сводятся к желанию игнорировать плохие новости, прятать под ковёр, и удивляться потом что они становятся катастрофой.
Хуже только бюрократы. В идеале их бы расстрелять на гильотине... но зная как работает система, по итогу окажется что именно они и решают кого расстреливать :)

1. Согласна полностью.
2. Логично. Надо искать кто посчитает.
3. Поняла, что это ключевая должность и ошибка может стоить дорого. Это, пожалуй, самая главная проблема для меня на сегодня.
4. Понятно)

Помогите советом про тех.специалиста))
Спасибо)

Теперь надо всё переписать «по уму» и добавлять новые функции — самая неблагодарная затея. Вы ж не заплатите нормально за качественное переписывание. Ведь наверняка это туева хуча НЕДОКУМЕНТИРОВАННЫХ фенечек.

Друпал 7 ещё в потолок не упёрся, точно говорю. Да, это потеря скорости. Но если срезать острые углы, уйти от его дебилизма переменных (по 2 таблицы на каждую), и плавно (и может не до конца) перейти на СВОЮ модель данных, отказавшись от модели Друпала — вполне себе будет живучий франкенштейн.

Большого слона едят по кусочку. Хотите эволюции — делайте всё последовательно. Потому что если одновременно рефакторить на новую платформу (или даже не сильно новую), дописывать функционал, добавлять новые фичи — и всё это попытаться сделать продуктом для инвестора (читай продать) — скажу что случится с вероятностью 100%: очередной баг приведёт к ссоре с разработчиком, вы получите недописанный проект с очень дорогой поддержкой, по итогу его взломают (возможно уже) — и к такому уже и фрилансеры не подступятся. А если подступятся — с каждой итерацией будет только хуже!

Настоящий головняк Drupal — это даже не его модель данных. Но интернационализация! Делать многоязычный сайт, отличающийся от того что дают стандартные модули — вот где ад и Израиль.

Выгода Друпала — то что он подразумевает вмешательство на обработке данных — через хуки — как нечто нормальное. То есть «хочу такого же, но с крыльями» часто совсем не проблема, тогда как на остальных платформах это может быть реальным гемороем. Но... делая хуки, ОБЯЗАТЕЛЬНО надо всё документировать, потому что стандартных средств документации там нет (считается что программистам самим виднее), и потому получить кучу непонятного (но работающего) кода — это очень распространено в Друпале. Как впрочем и в ему подобных CMSках, но именно в проектах на Друпале это выражено повсеместно: слишком велик соблазн сделать и забыть.

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

ОСОБАЯ ПРОБЛЕМА — если у вас стоят ворованные модули. Проблема в том, что их нельзя обновить. А вот дыр в них — часто и густо, и ломают через них сайты аж на ура. В том числе те, кто взломал для вас модуль — ведь ничто не помешало встроить бекдор. Потому если такие есть — лучше купить полноценные версии, или отказаться.

Если кратко:
— Не уходите с Друпала, если есть близкие бизнес-цели. Нужен новый функционал и фичи — пилите сначала их.
— Когда телодвижений по функционалу будет минимум (мёртвый сезон года, например) — тогда и будете прыгать на новую платформу.
— Документируйте все вмешательства в систему, все модули, так чтобы было понятно где, что, и ЗАЧЕМ. То есть не меняя сам основной код — навалите туеву хучу комментариев по всем сомнительным участкам, создайте себе отдельные мини-задачи на понимание этого, и ведите черновую документацию всего что нашли и поняли.
— Без подготовки в виде понимания где чего происходит в коде и данных — вы не сможете прыгнуть через пропасть рефактора. Просто недопрыгните. И вторая попытка ничего не даст, и последующие. Надо готовиться.

=========================================================================
PS. У меня есть несколько проектов на Друпалке (но для ограниченной аудитории предприятий и групп, они не публичны). Могу глянуть ваш (можно без личных данных или с краказяблами в полях личных данных, можно вообще без наполнения — но с пониманием СКОЛЬКО данных в каждой таблице). Разумеется конфиденциально, с последующей зачисткой всех данных на моей стороне (то есть если что-то потребуется повторно посмотреть — то надо выливать повторно).
Почему так: я очень серьёзно отношусь к безопасности, считаю чужие секреты священным граалем, и не считаю возможным в принципе знать чужие секреты. Как никто не узнает что именно я делал вам что-то, если только по этому не будет отдельной договорённости (она бывает крайне редко, обычно предпочитают не распространяться).

Что могу:
1) Существенно ускорить неповоротливого монстра. Найти где у него тяжёлые задачи, и добиться чтобы пахало как часики. По опыту, это в десятки раз быстрее потом пашет. Был прецедент ускорения в ≈100 000 раз (когда оказалось что собирались сырые данные, без которых можно обойтись в дальнейшем).
2) Прикрыть явные дыры безопасности, если нельзя сделать быстро — озвучить что и где надо сделать.
Что даст: кардинальный пинок проекту по скорости работы и требованиям хостинга. Позволит расти дальше без перестройки всего и вся, сосредоточиться на бизнес-задачах, отложив прыжок на другую платформу или новую версию той же самой. И тогда уже прыгать с минимальными издержками, шаг за шагом.
Консультацию дам нахаляву, без конкретики типа «куда нажать» и написания кода. Возможно этим всё и ограничится, если пациент здоров — тогда просто дам рекомендации и поздравления. Но так бывает практически никогда. Чаще всего на Друпал-проектах есть очень существенные проблемы по модели данным и по самописным модулям — которые тем не менее можно решить быстро и дёшево, и за ≈100 баксов получить снова живой, охрененно быстрый, и готовый развиваться проект — отсрочив тяжёлые перестройки и выиграв время на серьёзное переписывание.

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

Почему так: ваш бизнес растёт 65% в год. Так пусть растёт! Если там нет взрывной идеи, не факт что ему нужны инвестиции (а это крайне дорогой инструмент, зачастую необратимый). Возможно инвестиции стоит взять на более позднем этапе — тогда дадут на порядок больше! И гораздо дешевле по поиску инвестора.

PS. Одним из простых решений может быть просто смена хостинга. Так что лучше здесь на паблик скажите, сколько уже затянул проект гигабайт базы, файлов, какой хостер и тариф (если не у себя хостите). Может оказаться, что простой перенос на другой хост даст рост раза в 2-4 по скорости без вообще каких-то лишних телодвижений. В том числе повышением тарифа на существующем хостере или перенос на более быструю конфигурацию внутри того же провайдера. Это вообще обычное дело для веб-проектов — переезжать когда подросли.

Ух, много всего.. Надо ещё раз перечитать и осмыслить :)
Всё начиналось с идеи «Просто оставить всё как есть и добавить новое», но как-то не заладилось. Можно ещё раз рассмотреть эту идею.
В первые годы проекта был постоянный удалённый друпальщик, работал 1,5 года, ушёл. Затем ещё 1,5 года работала пара (они команда) удалённых фрилансеров. Ушли, говорят из-за большой загрузки по другим проектам, но я думаю, что потеряли интерес. Вернулся тот первый, помогает по мелочи.
Говорит, что ребята, которые были перед ним, очень хороши, профессиональные модули пишут и всё такое, что он на фоне их как ребёнок. Вот такая оценка.

Последняя цифра о размере нашей базы данных, которую слышала, была 6,5 Гб. Наверное сейчас больше.

Хостинг — выделенный сервер. Вроде нормальный, параметры надо смотреть.. Потом.

Пообщаемся позже, отпишу в личку.
Сегодня сложно, у нас корпоратив, нам 5 лет))

Не ведитесь на эти программерские сыроедские-понты. Больше 99% стартапов — задохлики без шанса выжить. Потому самое глупое что может быть в стартапе — слушать разработчиков, которым плевать на ваш стартап :)

Пение все правильно отписал на самом деле (что меня удивляет читая его другие посты). Проблема для бизнеса это вестись на плач недопрограмистов о том что надо все переписать

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

так если нет СТО — что ему делать? во всем мире является нормальной практикой нанимания консультантов в какой-то специфический области в которой фирма не имеет компетенций

так если нет СТО — что ему делать?

Смею предположить, что если нет СТО, то стоит его нанять?

Что как написали ниже — упирается в бюджет. ИМХО просто попросить для начала разовую консультацию в случае автора вполне разумный выбор.

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

Советы помогают определить на сколько нужно заинтересовывть, и кого.

Мой совет проверен десятками лет: НУЖНО ИЗБЕГАТЬ внутренних перемен, если идёт рост. Нужны перемены — ждём штиль, ждём мёртвый сезон, и тогда. Исключение — если рост стремительный и глобальный, то есть проект выстрелил. Тогда нужно просто решить вопрос времени — деньгами, либо... опять же деньгами доплатить за скорость железа, чтобы оттянуть вопрос изменений.

Почему так: РИСК — вот что у стартапа непосильная задача. Стартапы платят за него смертью. А когда это уже не стартап — то риск нужно ограничивать, применять менее рискованные шаги. В этом мой совет.

Мой совет проверен десятками лет:

Только вот этого не надо..

Нужны перемены — ждём штиль, ждём мёртвый сезон, и тогда.

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

. Пока будешь ждать штиль и мертвый сезон, конкурент выкатит более быстрый, удобный и актуальный
сервис

Вот-вот!

Не «вот-вот», а зафейлится. Угадай, к кому утекает трафик зафейлившихся проектов :)

Есть перемены которые постоянны и непрерывны — дизайн, контент, маркетинг, качество. А есть технические, про которые говорят «два переезда равносильны одному пожару». И вот последние делают в мёртвый сезон. Который, кстати говоря, СЕЙЧАС.

Все правильно говорите. Согласна, надо искать СТО. Где и как?

Пение все правильно отписал на самом деле (что меня удивляет читая его другие посты).

Я просто редко пишу на технические темы, и на темы в которых имею экспертизу. Поскольку ограничен участием в проектах, откуда собственно эти знания берутся. Мне интересно обсудить вопросы, где я не имею 100% уверенности, и потому хочу услышать чужое мнение. Но чтобы понять где противоречие, в чём я не прав — приходится высказать своё. Так что уже на завтра я могу быть не согласен с тем, что написал вчера — и в этом цель :)

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

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

Профессиональные модули? Насмешили. Друпалу пофиг, кто пишет его модули :)

При базе 6.5 гектар — сразу скажу что потребуется оптимизация самой базы. И очень вероятно — миграция в сторону Percona+TokuDB но это потребует некоторых допущений по самой базе, отказ от такой «мелочи» как ForeignKey (который формально даёт поддержку целостности базы). Результат — скорость и меньше требования к оперативе. Ну и SSD не так быстро изнашивается.

Отдельно стоило бы проверить параметры SSD — он имеет свойство изнашиваться. Но это потребует root-полномочий, так что лучше попросить поддержку хостинга проверить параметры. И если изношен — возможно потребуется заменить физически, за ваш счёт, если сервер ваш, а не арендованный. За 5 лет вполне мог сдохнуть.

Возможно (но пока не факт) имеет смысл купить сервер, и поставить его на collocation (а не арендовать). Либо же на арендованном пересмотреть конфигурацию — к примеру, больше оперативной памяти сделать (и это может стоить денежку, особенно если понадобится переезд на другое железо). Но это всё только ПОСЛЕ анализа, как что работает. То есть чтобы взвесить за-против, и не оказалось что после оптимизации новый сервер будет загружен на 10% (то есть старый не надо было менять).

Основная работа всё же по базе. Зная Друпал, могу сказать основное направление: НАХРЕН избыточную индексацию таблиц!

PS. Ну и разумеется нахрен ревизии, с дублированием всех таблиц. Это сразу база вдвое меньше. Хотя они и неотключаемы в системе совсем, но есть вполне надёжные хаки которые это делают. На 7 Друпале я это применил не только лишь везде.

Вот история успешной компании Lemon Brazers, можете повторить
cont.ws/@gopanaha/179118

Не интересует)) Но смешно)... И грустно(

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

Бизнес которому 5 лет — уже не стартап. Забудьте это слово! Потому что оно означает рост цены привлечения средств на порядок. Мало кто хочет вкладываться в стартап, глядя в завтрашний день

Що за проект, можна ссилку на вебсайт?

Да, уже несколько человек настойчиво рекомендовали.

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

А потом через пару лет окажется, что PHP в принципе тормоз, и он не тянет? Так не лучше ли провести эти 1-2 года на Друпале, зарабатывая и не тратя, и уже тогда переписать всю логику на Java.

Ускорить существующее можно всегда — скорость продаётся. Вопрос только в безопасности. Но переписывание всего — это деньги. А деньги надо СНАЧАЛА заработать, потом тратить. Инвестиции же означают привлечение ещё одного собственника — и чужое руководство де-факто, и это огромный риск. Не значит что будет всё плохо, но значит потребуется «переписать всё» и в руководстве — а оно вам надо сейчас? Позже — возможно.

Спасибо за поздравления)) Так то, оно так... но можем еще «закосить» под стартап и попытаться найти инвестиции на развитие.
Плюсы этого решения:
Возможен резкий рост в доходах, сейчас где-то 65% в год. И поисковики и пользователи любят быстрые удобные сайты. Знаю ЧТО надо сделать, не знаю КАК.
Минусы:
— Не понятно сколько надо искать денег.
— Могут не дать.
Второй вариант — рассматривать это как бизнес и делать всё тоже самое, но со своей прибыли.
Плюсы:
— не надо ни с кем делится.
Минусы:
— быстрого рывка не сделаешь. Так и будем по чуть-чуть складывать копеечки и собирать на зарплату разработчикам.

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

Закосить под стартап стоит если:
— Идея революционная, и революция — в самой идее.
— Это можно оформить как интеллектуальную собственность.
— Сложно повторить (есть ноу-хау которые совсем уж не очевидны даже одному из миллиона).
— Может выстрелить став глобальным брендом, или локальным — но в богатой локации.

В остальных случаях инвестирование это: трата денег и убийство проекта, не без помощи «ценных советов» инвестора. Это всё равно что 4-летнего ребёнка отдать в солдаты, потому что он соседскому мальчишке успешно посадил фингал. Плюс инвестор (местный) может заявить что он работает не по закону, а по понятиям, и тупо вы должны ему денег, а счётчик тикает.

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

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

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

Согласна по всем пунктам. Уже поняла, что надо искать СТО. Вопрос: как его искать, где и на каких условиях?

СТО вам нужен, если техническая часть — ключевая особенность данного проекта. Если же технически он ничего особенного, там идея и маркетинг — то лучше отдать на аутсорс. CTO имеет смысл если вы туда хотя бы 20 000 долларов хотите вложить в техническую часть, и своих, не инвестора. Сильно сомневаюсь :)

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

О, наконец прозвучала хоть какая-то цифра) 20 тыс. в какой период?

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

Как вы можете ожидать реальную цифру от тех, кто проекта в глаза не видел, даже снаружи! Чтобы написать «с нуля» времени и денег нужно куда меньше, чем переписать готовый проект. Почему так: куча всего разного, чаще всего НЕ ДОКУМЕНТИРОВАННОГО, работающего непонятно как, но работающего.

Почему так: ошибки. Когда код документирован, хотя бы понятно КАК ЗАДУМЫВАЛОСЬ. Когда нет — невозможно отличить ошибки от костылей.

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

Почему сложно сказать цифру заранее: потому что непонятно, там фронт работы на годы командой, или на неделю одному, или на полчаса. Обычно, если ничего серьёзного менять не надо, а только отрефакторить часть кода в сторону производительности — то лучше всё делать одному человеку. Потому что рефакторинг штука сложная, задействуется сразу всего и много, и что-то мне подсказывает, код не покрыт тестами от слова «совсем».

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

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

На моей практике, фреймворком лучше оставить Друпал, а бизнес-логику писать на чистом PHP, друпал не задействуя. Равно как и на других языках — например скрипты для регулярного обслуживания базы данных куда приятнее написать обычным шелл-скриптом (аналог bat-файла), которые тупо закронтабить.

Результат всё тот же: скорость, за счёт уменьшения объёма работы на частых операциях. А редкие операции — пусть колбасятся на Друпале, они не мешают.

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

ПРОСТАЯ ЗАДАЧА: сделать на боевом сервере копию проекта, лишив его данных. С другими правами доступа к файлам (опционально, но желательно), с другими паролями к админу и к базе. И выделить отдельное доменное имя на DNS домена, что-то вроде test-poligon.ваш-домен.ком — так вы сможете точно знать, что обвалит обновление безопасности или модуля, потестировать собственноручно как что работает, прежде чем обновить на боевом сервере.

Почему так: хотя у разработчиков есть своя копия, всё же проверять нужно в реальном окружении как и что работает. Особенно когда разработчиков несколько, или нет совсем постоянного.

СТО вам нужен, если техническая часть — ключевая особенность данного проекта.
Наш стартап в сфере Веб (типа маркет-плейса в сфере услуг)

Разве из описания не следует то, что техническая часть — ключевая особенность данного проекта? То, что она реализована единожды и не развивается — не меняет ее ключевое значение.
Аутсорс — может исполнять принятые решения, и отдать реализацию на аутсорс может быть вполне оправданным решением. Но только отдавать на аутсорс принятия решений о том, что делать с «ключевой частью проекта» — это детская ошибка большинства стартапов. А так же не иметь возможность адекватно оценить эффективность исполнения — тоже очень серьезный риск. Поэтому иметь бизнес, в котором основной канал продаж идет через веб без человека, который будет отвечать за работу и развитие этой части бизнеса — путь довольно рисковый, хотя как видим вполне живоспособный на протяжении 5 лет.

Поэтому иметь бизнес, в котором основной канал продаж идет через веб без человека, который будет отвечать за работу и развитие этой части бизнеса — путь довольно рисковый, хотя как видим вполне живоспособный на протяжении 5 лет.

Ну, как бы, я и отвечаю за работу сайта. На уровне: работает — не работает. Знаю что я не спец... Но шо маемо, то маемо..

Вот с этим, если честно, не подскажу.

Кого искать в развивающийся стартап

Инвесторов и клиентов

По инвесторам очень спорно. Это ж не добрые дяди с крылышками

Тяжёлый, медленный сайт, который не возможно маштабировать, внедрять новый функционал.

Нет. Мы что-то типа Пром.юа, но в сфере услуг. На нашем сайте продаются услуги от других компаний. Эти другие компании, платят нам деньги, потому что мы «реально красавчики» и приводим к ним клиентов.
Теперь планируется серия улучшений, как для конечного потребителя (более удобный каталог, фильтры, сортировка, поиск), так и для этих компаний (удобный личный кабинет, онлайн оплаты и др).

Наоборот, нужен по Друпалу. Там в самом Друпале тормоза хорошие заложены. Особенно если его не по назначению пользуют.

Вот насчёт «невозможно масштабировать» — очень спорное заявление. Если там вся логика на Drupal, то переход на MongoDb заставляет этого страуса летать. Другой вопрос, что с самой Монго работать неудобно, и сторонние средства аналитики с ней не сильно дружат (понадобится писать или использовать прокси-компоненты). Но тут уж или какать, или банан.

Другими словами, «невозможно масштабировать» можно заявлять только обострив противоречия. «Медленный» — это не противоречие, скорость купить не проблема.

Наверно нужен Техлид или PM?

Не наверно, а точно. Причем если у вас возник подобный вопрос, то в вашем случае не «или», а «и». Обычно, в стартапах, когда дело доходит до переписывания MVP, то в команде уже есть CTO, который и берет техлидские обязанности на себя и тогда задача становится найти толкового ПМ и собственно разработчиков. В вашем-же случае, судя по всему нет СТО, который бы мог задавать вектор с технической стороны и нет ПМа, который бы взял на себя задачи управления командой и обязанности скрам-мастера.

То есть, надо определится сколько искать денег, каких специалистов, на каких технологиях разрабатывать.

Срочно ищите СТО.

Офис находится в Одессе. Искать офлайн спецов или удаленных?

Это дело личное. Кто-то легко работает с удаленными сотрудниками, кто-то предпочитает загонять людей в офис. Я считаю в наше «онлайн» время, да еще и когда речь идет о стартапе — настаивать на офисе не очень хорошая идея. Не инновационно это ;-) Хотя в будущем, когда стартап станет бизнесом, а количество разработчиков значительно увеличится, то возможно и появится смысл работы в офисе.

Есть мнение, что из-за того что главный основатель — женщина, это тоже может вызвать некоторые проблемы. Это так? :)

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

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

Ой, спасибо :) Что значит пингуйте?

Обращайтесь ;-) Скайп есть на странице профиля.

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

А откуда он берется обычно? Если изначально его не было...

От найма близкого по духу человека :-)

Не ведитесь на эти стараперские смузи-понты. Больше 99% стартапов — задохлики без шанса выжить. Потому самое глупое что может быть в стартапе — слушать других стартаперов :)

Я тоже из Одессы, предлагаю себя в качестве IT консультанта чтоб синтезировать для вас бизнес систему по которой вы сможете определить дальнейшие шаги

И к Вам обращусь) Рады любым советам.

Поскольку это явно не рокет-саенс отдайте кодированое на аутсорс, а сами вплотную занимайтесь бизнес-вопросами — дальнейшим развитием функционала и раскруткой.

Аутсорс высосет весь бюджет, провтыкает все сроки и в итоге не выкатит продукт. Тогда уж аутстаф.

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

Если мы говорим об аутсорсе, то никакой нормальной сыгранной команды не будет. Вместо этого продадут пачку джунов по рейту сеньоров, которые и будут педалить проект с нуля. Такая практика замечена даже за именными компаниями. Да и отношение в компании к тебе, как к заказчику, будет на «отвали». Если ты, конечно, не получил госзаказ с финансированием от правительства Австрии с объемами работ на 2-3 года. В модели аутстафа картина значительно лучше, там действительно можно получить сыгранную команду, но тогда проблемы управления командой никуда не деваются.

Ну если работать за Т&М так и будет. Если прописать четкие требования и фиксед-прайс — нет. Повторюсь — тут явно не идет речь об уравнении с многими неизвестными. Если оно сейчас работает на Друпале — любого шаблонного CRUD- решения будет более чем достаточно.

Аналогичная ситуация уже была с компанией специализирующеся на Друпал. Брали почасовую оплату, считали каждую секунду и самое главное, что больше всего бесило, что их «разработчики» понимали в Друпале меньше чем я.
Говорят: «Сделали — проверяйте». Проверяю — УРЛы не те, фильтры не работают. Говорю: «Не работает это и это». Ушли переделывать. Снова, сдают, снова не работает. В итоге, значительно позже это задание сделал фрилансер с биржи. А эти мне всё время посчитали по полной программе, и переделки, и общение, и проверку. В итоге я потратила кучу времени, денег, а результата так и не дождалась...

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

Думали и об этом. Но, как маркетологу, мне хочется и эту фичу и ту, и ещё вот здесь изменить, и вот это внедрить. Тогда мы с аутсортсом должны пожениться))

Если у вас не будет четкого плана внедрения фич вы влетите, как со своей командой так и с сторонней. Начинайте с написания роадмэпа.

Согласна. Но чтоб написать дорожную карту надо обладать соответствующими компетенциями и опытом. Если б это было, то и вопросов бы небыло.

Вы не видите путей развития вашего сервиса?
Кстати, какая у вас мотвация ухода с Друпала? Чего вы хотите достигнуть переходом на самописный сервис?

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

Да, скорость сильно напрягает. Денег не предлагаю, спрашиваю сколько хотят и потом смотрю по доходам: в этом месяце делать или подсобрать надо.

На сайте слишком много скрытых ошибок и скорость низкая. Чтобы внедрять что-то новое, надо навести порядок в том, что есть. За весь прошлый год (постоянные фрилансеры делали) подшлифовали чуть-чуть мобильную версию и добавили прикольную фичу с картами Гугл, всё остальное время ушло на исправление критичных ошибок (не критичные до сих пор остались). Это демотивирует и меня и разработчиков. Время идет, ничего не происходит.
Начала думать, над новым сайтом. Спросила сисадмина сервера (постоянный фрилансер, года 3 работаем), спросила разработчиков, которые привлекались к проекту. Все поддержали идею, но это не их профиль. Рекомендуют Питон, фреймворки...
Но, если в Друпале я более менее понимаю (всё что можно было сделать без написания кода, делала сама). то всё остальное для меня темный лес. Могу понять только на уровне «звучит логично» или «что-то меня смущает этот вариант». :)

Заложите в ТЗ возможность конфигурации нужных вещей через админку.

Да. Думала об этом. Это большой плюс CMS — пару часиков и готов новый раздел сайта)

Рекомендуют Питон, фреймворки...

Любой современный стек подойдет. Пайтон, руби, джс, пыха — не важно.

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

p.s. Конечно, если муж ещё не найден. Тогда все печально

но со своим Друпалом упёрлись уже в потолок.

В какой потолок?

Я тут ездил на ланосе, работу работал, но теперь его не хватает, какую мне взять теперь машину?

Сайту 5 лет. Медленный. Кучу времени и сколько-то денег выкинули на «переписать запросы к бд и разогнать», но результат всё равно не фонтан. Банальное обновление безопасности превращается в 3 недели работы и потом ещё надо отыскать где что сломалось и отладить.
При попытках внедрить, что-то новое, все потенциальные исполнители берутся, вникают и.. отказываются.

Переписать запросы к БД для Друпала не сильно помогает — львиная доля запросов у него встроенная. Чтобы его гнать, там надо вообще выносить логику за скобки Drupal.

Обновление безопасности на седьмом друпале три недели? Не смешите мои тапочки. Он же не развивается, там уже ничего не меняют. Ломаться ничего не должно.
Почему я и не рекомендовал слезать с Друпала 7: либо функционал развиваете, либо меняете платформу. Начнёте одновременно — всё развалится. Куда проще сначала функционал, потом когда уже всё работает — пробуете реализовать на чём-то ещё (если это вообще нужно).

А по поводу «разогнать»... расскажите что это такое? Я знаю что так можно только клиенту по ушам поездить.

Насчёт кучи времени — оно для вас критично? Если вам не мешало это вести бизнес — то это не ваше время, так что всё сводится к «несколько денег».

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

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