Неуспешный стартап и полученный опыт

Эдисону приписывают слова "у меня не было 10.000 неудач, я всего лишь изобрёл 10.000 способов, которые не сработали".

Чуть больше месяца назад закрыл "свой" стартап. Проект был небольшой, в команде всего 4 человека (бэкэнд, мобильное приложение, веб, администрирование окружения). Какой же опыт я извлёк из этого "способа, который не сработал"?

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

Ведь в противоположном случае на рынке было бы только по одному игроку в каждом сегменте, а это не так.

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

Конечно, не стОит воспринимать совет буквально - задумка написать второй facebook или linkedin, пожалуй, окажется безрезультатной (хотя и такие попытки регулярно встречаются).

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

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

* Люди - участники стартапа - должны "гореть" идеей, желанием и стремлением. Именно это является в стартапе одним из важнейших конкурентных преимуществ. Именно это позволяет "догнать и перегнать".

Пожалуй, это вообще самая главная особенность стартапа и необходимое требование для его успеха.

В общем, стартап - это не 8-мичасовой рабочий день. И вообще, он не измеряется рабочими часами.

*  Ещё - д.б. классные разработчики. Не узкая специализация и фразы "а как же без макетов?", а работа один-за-всех / все-за-одного. И небольшая команда, люди в которой подходят друг к другу в плане совместимости.

* Стартап должен быть быстрым и активным.

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

Если "идёт" - продолжать работу. Если "не идёт" - бросать сразу же. Потому что бросать через год - намного более жалко.

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

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

Но "вылизанное" с технической точки зрения приложение может просто быть никому не нужным.

И в заключение - процитирую слова одного из участников, сказанные им после закрытия проекта:

"Никого не хотел обижать, но был уверен, что к этому придем, с самого начала. Увы. :("

Эти слова "сделали мой день"...

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

Прокрастинация, будь она неладна...

Умное слово "прокрастинация" нынче используется направо и налево. Его основное достоинство - им можно красиво объяснить нежелание делать хоть что-то.

Ну, как бы, есть где-то такое слово, есть у кого-то такая ситуация - и ладно бы с ними.

Но - shit happens... пришло понимание, что при всей собственной самоорганизованности, дисциплине и склонности к management of time and life - меня это тоже касается :(

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

"Признать, что вы прокрастинируете, — отличный первый шаг..."

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

"... но этот шаг будет абсолютно бесполезен, пока мы не начнём менять свой подход к делу".

Ага, мудрых советчиков в сети масса; но если не тратить время на чтение статей о том, как не тратить время на ... ну, вы поняли - то что делать-то?

Работать не модно?

Недавно забрался на славный habrahabr и прочитал "3 года «Чёрной книге менеджера»: что изменилось в индустрии? Интервью со Славой Панкратовым".

О патриотизме в компании

Жила-была некая IT-компания. Как и прочие, она появилась на свет в виде стартапа, который затеяли и развивали несколько человек.

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

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

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

Процесс вливания новичков в коллектив и восприятия духа замедлился - у кого воспринимать сложившуюся культуру компании, если два сотрудника из трёх ею не владеют? К тому же, процесс осложнился (и осложняется в настоящее время) постепенным уходом "старых" людей.

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

К чему это всё? Ах да! К тому, что в результате такого взрывного роста и расширения особенная атмосфера попросту рассеялась и расплылась. А от коллег встречаются слова (не дословное цитирование, но близко к тексту): "Я не патриот компании. Я просто делаю работу, за которую мне платят".

Возможно, это естественный процесс. Но как "старожилу и патриоту" от понимания этого становится грустно.

Управление ресурсами

Тайм-менеджмент и контроль личных денег: что общего?

Уже неоднократно встречал у разных людей негативное восприятие и отношение к тайм-менеджменту. При этом один из аргументов contra - само понятие планирования и бюджетирования времени. Мол, как же так, если я буду планировать каждый свой день и затем жить по этим планам, мне останется ещё меньше свободы. Ещё меньше возможности сделать что-то не по плану, случайно. Ещё меньше "воздуха" в и так связанной по рукам и ногам жизни.
Аргумент понятный и на первый взгляд достаточно сильный. Ведь при быстром темпе жизни, когда задачи возникают регулярно и словно ниоткуда, когда эти задачи зачастую привязаны ко времени и требуют оперативного решения, не хочется навязывать себе ещё какие-то дополнительные планы.

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

Про опыт и стаж

Первоначальные материалы в "старой, но актуальной теме про коллектив" Евгения Охотникова и по ссылкам далее.

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

Например, зацепил описываемый в третьем разборе тов. bulochnikov'а случай - случай аварии на предприятии (про опытного слесаря и разудалого мастера, а также перепутанную маркировку фаз).

Думается, что в последнее время (читай - годы) наблюдается тенденция/мода на регулярную смену работы. В том числе в IT-сфере как молодой и активной. Особенно в больших городах, где предложений работы больше. Особенно (imho) среди управленцев.

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

Но описанный пример отлично иллюстрирует тот факт, что не всё - далеко не всё - можно проверить, отладить, описать в документации и пр. и пр. И только сотрудники, работающие в компании длительное время, в состоянии в нужный момент вспомнить, почему конкретный участок кода выглядит так странно, компоненты взаимодействуют каким-то удивительным образом, а в конфигах встречаются вроде бы нигде не используемые параметры. Вспомнить и удержать от попыток переписать код "по-красивому", подключить компоненты напрямую, а параметры вчистую выкосить. И избежать тем самым epic fail'ов и просто глупых и неожиданных проблем.

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

Тема особенно актуальна, когда коллектив регулярно теряет своих "старожилов". Вот бы ещё руководство компаниями это хорошо понимало...

update: оставлю ещё ссылку на http://one-in.livejournal.com/68355.html

ДОделывать или ПЕРЕделывать?

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

lifeline vs. deadline

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

Также это выражение закрепилось и в сфере управления временем/задачами/жизнью. Используете to do list - и для перечисленных дел указываете крайний срок, когда дело должно быть сделано? Вот он, крайний срок, к которому задача должна быть решена и вычеркнута. Вычёркивание задач из списка дел в конечном итоге завершится вычёркиванием всей вашей жизни - самым крайним и неоспоримым дэдлайном.

Может, стоит мыслить по-другому - "не deadline и не конец, а lifeline и начало"? Мыслить в терминах нового дня, новой недели и нового старта.

Возможно, от перемены слов суть не изменится. Но ведь "назовёшь его корытом, так оно и поплывёт"! Так что пусть будет lifeline, хотя бы иногда.