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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Unsupported major.minor version

Порой при запуске java класса/jar/приложения и т.д. можно "словить"

java.lang.UnsupportedClassVersionError: название класса :
 Unsupported major.minor version 51.0

Причина заключается в том, что класс был скомпилирован на версии jdk более новой, чем та, на которой этот класс теперь запускается. Например, скомпилирован на 1.7, а запускается на 1.6 и т.п.

Узнать текущую версию jdk можно консольной командой java -version

А вот как определить, какой версии class-файл? Узнать версию jdk, использованную при компиляции, можно по числу в описании ошибки (51, 50 и т.п.) или по самому class-файлу. Любой класс имеет определённую структуру (детали - в документации по его формату, например, https://docs.oracle.com/javase/specs/jvms/se6/html/ClassFile.doc.html#80959). В частности, начало выглядит примерно так:

CA FE BA BE 00 00 00 2E

Файл начинает с magic number CAFEBABE, а за ним следуют два short-а, составляющие minor и major части версии соответственно.

Поэтому можно открыть class-файл в hex-редакторе, найти значение и определить версию по следующей таблице:

2015#10 notes

Ненастоящие сеньор-девелоперы, или почему годы опыта ни о чем не говорят - перевод поста одного товарища из Торонто на тему джуниоров, мидлов и сеньоров. Интересный критерий ранжирования, вполне себе логичный. Особенно с авторским примечанием "это просто гигантское упрощение" :).

31 год, миллиардер: Элизабет Холмс совершила прорыв в медицине. Однажды я "повёлся"-таки на контекстную рекламу и оказался на странице со статьёй о Theranos и Холмс, затем посмотрел её выступление на TEDMED 2014.

Как люди запускают крупные, крутые и реально дорогие проекты с нуля? Чаще всего - они работают, днями, неделями, месяцами и годами. И постепенно встречают и деньги, и бизнес, и удачные стечения обстоятельств.

И хотя недавно журналисты The Wall Street Journal обвинили Элизабет Холмс (Theranos) в обмане, всё равно первая статья меня зацепила.

Organizational change myths and patterns for Evangelists by Linda Rising, выступление на FlowCon San Francisco 2013.

Посыл: люди нерациональны в принятии своих решений. Поэтому, если вам необходимо донести идею (любую, хорошую/плохую), то не нужно придумывать рациональные аргументы  и в мелочах продумывать PowerPoint презентацию - в первую очередь вы должны их убедить, что вам можно верить. И тогда они купят то, что вы продаете.

И паттерны:

• evangelist (с религиозным оттенком) - вы должны сами гореть идеей;
• share food - вкусные печенки добавляют +100500 к убедительности;
• угрозы ведут к соблюдению требований, но не к приверженности идее (compliance but not commitment);
• индивидуальный подход к убеждению решает очень многое;
• скептики - это НЕ плохие парни, которых нужно игнорировать, но путь к познанию и улучшению.

Так что - рекомендую.

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

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

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

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

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

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

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

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

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

Tortoise icons overlay

Давно использую TortoiseSVN / TortoiseGit для работы с этими VCS. И как-то привык к специальным иконкам - с их помощью можно очень быстро понять, в каком состоянии директории и файлы, изменены ли они, находятся ли в ignore-состоянии и пр. и пр.

На новом рабочем месте установил себе TortoiseGit 1.8.15 и... - не увидел привычных оконок, вместо них был обычный win-style. Все стандартные настройки в settings (TortoiseGit's settings, figures 2.65-2.67) присутствовали. Из-за занятости решение проблемы пришлось отложить, поработал пару недель без них. Привыкнуть тоже можно, конечно, но с ними лучше ))

А потому недавно выбрался в интернет в поисках решения - как перекрыть иконки для  TortoiseGit?..

Забавный баг

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

История случилась несколько месяцев назад, когда мы в Intervale проводили интеграцию с Maxima Telecom в рамках проекта vmet.ro (он же wi-fi.ru).

"Переведи мне" в Беларуси

Рад за бывших коллег из Intervale, что проект "Переведи мне в Беларуси" наконец запущен. Знаю, какие были сложности (не технического, но организационного и договорного характера), поэтому здорово, что их удалось разрешить. 

Вот презентация на onliner.by: MasterCard разрешила пользователям своих карт переводить деньги вне зависимости от банка.

Новость на портале самого банка: "Переведи мне! - новый сервис БПС-Сбербанка!"

И, собственно, страничка сервиса "переведи мне".

2015#09 notes

Выступление "One Hacker Way, a Rational Alternative to Agile" Эрика Мейера на Reaktor Dev Day 2014. Начало выступления, посвящённое полному отрицанию agile'а, можно считать скандальным вбросом для того, чтобы вызвать бурные комментарии и сражения. Обещанная альтернатива так и не была особенно детализирована. Но всё равно - классная энергетика и драйв стоят просмотра.

Motley says: "To be a lead developer, all you need is technological know-how". Что значит быть "ведущим" специалистом? Вопрос частый, вопрос важный, вопрос спорный... Автор описывает своё видение: "a lead developer must lead from several different perspectives, including people, process, and technology".

On Being A Senior Engineer - трёхлетней давности пространное рассуждение о степенях зрелости для разработчика. Откровений не встретил, но было интересно прочитать.

Книгу Денни Стригла и Фрэнка Свайтека "Менеджерами не рождаются. Непростые уроки достижения реальных результатов" (Managers, can you hear me now? Hard-hitting lessons on how to get real results by Denny F. Strigl and Frank Swiater) прочёл по рекомендации тов. eao197. Люди делятся своим богатым опытом, приводят практические примеры, дают классные и действительно стОящие рекомендации и советы. И честно говорят - само прочтение книги ещё ничего не означает, но понимание и использование её идей в собственной ежедневной практике - это ключевой момент.

Jboss Wildfly 8 HTTP response headers

Вопрос: как сконфигурировать web-сервер в jboss 8/9 для того, чтобы подставлять в ответы важные и нужные http-заголовки?

Конкретный пример: для обеспечения кросс-доменных запросов надо бы добавлять заголовок Access-Control-Allow-Origin. Ну, и до кучи ещё пару связанных (Access-Control-Allow-Methods, Access-Control-Allow-Headers). Ясно, что это надо не в прикладном сервлете/контроллере код писать, а настраивать сам сервер. Как?

Ответ далее в статье.

Spring MVC пример контроллера

Нужен HTTP-сервер? Не вопрос, используем java.net.ServerSocket, будем принимать входящие соединения, затем socket.getInputStream(), прочитаем данные и...

Стоп! Эдак придётся байты в строку переводить, потом выделять метод, url, заголовки, тело - столько всего! Можно проще?

Можно! Spring MVC - наше всё :) Далее в посте - пример создания контроллера с удобным маппингом.

(ну, по справедливости, можно сделать проще и без spring'а, но я же ведь как раз про него пишу:) ).

PayUp и его рекламный ролик

А вот и видеоряд сервиса PayUp:

P.S. http://itech-notes.blogspot.com/2014/09/pay-up.html

Цепочка 'почему?'

Начинаете новое дело? Хотите понять, что в вашей жизни важно? Участвуете в обсуждении рабочих задач с коллегами?
Просто спросите "зачем?"

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

Собственно,
зачем? Чтобы отбросить поверхностные, несущественные детали.
Зачем? Чтобы постараться и найти глубоко лежащую, коренную причину/цель.
Зачем? Чтобы стремиться именно к желаемой цели и решать именно исконную проблему (лечить заболевание, а не симптомы).
 

Ну, в целом понятно.
Надо понимать, что до бесконечности копать не следует. По моему мнению, 3-4, максимум 5 итераций вполне достаточно.

Вот несколько примеров от умных людей :)

 

На курсе основные практики архитектора ПО тренер Александр Уланов обращал внимание участников - архитектору обязательно нужно общаться с заказчиком и через серию уточнений-вопросов "Зачем? Почему? Для чего?" выявлять, что же требуется реализовать. Чтобы удовлетворить базовую потребность заказчика, а не какие-то "левые" идейки.

 

Евгений Охотников у себя приводил пример из книги Коллинза и Порраса "Построенные навечно. Успех компаний, обладающих видением". Саму книгу я не читал, каюсь, а вот цитату из поста приведу:

Определение реальных причин и целей существования компании. Упражнение под названием "Пять почему?": начинается с простой констатации факта, вроде "Мы предоставляем услугу X", после чего задаются вопросы "Почему?". Например, "Почему предоставление услуги X важно для компании?". После чего к полученному ответу применить вопрос "Почему?" еще раз и т.д. несколько итераций.

Вот ещё очень интересный опрос от Макса Пастухова, в котором речь идёт, по сути, о том же:

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

В общем, можно этот подход назвать цепочка 'почему?' (ну, или 'why' / 'what for' chain для тех, кто очень любит английский :))

Подход, который одинаково полезен и для бизнеса, и для работы, и для life management.

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

P.S. Если у кого-то есть примеры по теме - поделитесь, пожалуйста.