Pull to refresh

Comments 21

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

Проект разрабатывался 16 месяцев, доводился до совершенства. Был готов к нагрузке и обвешан тестами по самое не балуйся. Технически он был идеален.

Но:
1. Разработчики выдохлись, они видели результат только на dev машинах и отчеты тестеров.
2. За время разработки ландшафт изменился и изначально привлекательная идея была разгромлена несколькими уже запущенными проектами
3. Получивший монстр мог всё, но большинство из функций было нужно только воображению менеджеров.

Такие дела.
Коль скоро вы говорите сейчас у вас получился пример успешного запуска проекта — он хоть какие-то деньги уже приносит, или статус «Beta» ещё будет висеть неопределенно долгий срок? Все-таки весной запустились — уже полгода прошло практически. Т.е. разработка вышла 1.5 месяца… а сколько это по деньгам получилось? И как искали разработчика, который все это так здорово за 1.5 месяца замутил? И в конце-концов, куда вы дели половину того несчастного разработчика, кто не дожил до момента сдачи прототипа, заказчику?
Половина разработчика — это я, и я не несчастный ;-). Целый разработчик — это друг со школы и университета, с которым мы до этого работали над буруками, теперь он руководит разработкой sociate.ru

Проект запустился полтора года назад, в 2012 году и он полностью обеспечивает себя со второго месяца работы. Я не говорю,, что наш опыт можно повторить и со 100% вероятностью запуск будет успешен, вариантов масса, мы лишь предлагаем «один из»
Кратко статью можно охарактеризовать известной фразой: «Лучшее, враг хорошему».
Вопрос. А почему питон и джанго? Выбирали язык и платформу под требования проекта или просто изначально оба уже имели большой опыт разработке на данной платформе?
Второй вопрос вдогонку. Вы говорите что лучше брать порой готовые решения, даже если может потребоваться немного заплатить за них. Если не коммерческая тайна, можете показать содержимое requirements.txt(какие библиотеки питона и джанги брали готовые)?
Питон и джанго потому, что мы их знали. Не теряли время на изучение. req.txt — весь бесплатный, мы платили только за амазон, рассылку смс (транзакционные, а не спамные ;-)) и сервера помощнее, чтобы не заниматься оптимизацией кода в первые дни.
Просто любопытно какой набор библиотек использовали. ;-)
Нагрузка сейчас(и в пиковые дни) какая в сутках?
Амазон ради s3 и выноса туда статики?

Администрирование сервера своими силами осуществляете или привлекали дополнительные человеческие ресурсы? Сервер выделенный или в облаках? :)
Всё сами.

Библиотеки — только по надобности, ничего лишнего и ради украшательства. Сам список не будет полезен публике, он решает именно наши задачи
Амазон — да, ради s3 и ses.
И то и другое вполне себя оправдывает.

Нагрузка на фронтенд мало что скажет, т.к. основная часть ресурсов задействуется на бэкенде.
Третий вопрос в этой теме. :)
Проектирование, тз, цели, расписание этапов(альфа, бэта, ...).
Как много времени вы потратили на проектирование и как много на чисто техническую сторону?
Я про альфа версию, когда вы ещё не видели готового продукта с мнениями пользователей.

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

1.5 месяца — только разработка.

Продвижение шло за счет сарафана и партнерской программы.
Согласен с каждым словом автора статьи. Лично я всегда был приверженцем MVP. Пару лет назад работали с одним заказчиком из солнечной Канады — ему надо было сделать что-то вроде сервиса поиска попутчиков («Такого-то числа еду из Торонто в Оттаву, есть 3 свободных места»). Я ему предлагал много раз выпустить сервис с минимальным набором функций и изучить отзывы пользователей, а, затем, избрать дальнейший вектор развития. Но… Он захотел кучу невразумительного функционала, который, от силы, мог бы пригодится 10 пользователям из 1000, плюс к этому, за неделю до предполагаемого релиза, ВНЕЗАПНО решил поменять дизайн. В результате, мы свою работу сделали, получили за это деньги, а сервис так и умер не родившись, т.к., по сути, был никому не нужен в том виде, в котором он получился.
Если работа идет на заказчика — максимум можно советовать ему и не принимать близко к сердцу странные на ваш взгляд вещи, все-таки он платит деньги. А если речь о собственном проекте, то мы за МВП
Основная проблема того проекта была в том, что вещи были объективно странные :) Плюс, невнятная модель монетизации: пользователи должны были оплачивать подписку, которая, по сути, ничего им не давала, кроме расширения функционала личного кабинета — возможность «зафрендить» пользователя, добавить объявление в избранное. Т.е. всё то, что должно быть бесплатным и по-умолчанию доступным любому зарегистрированному пользователю.
Sign up to leave a comment.