Шпаргалка для предпринимателя по IT-миру

Бизнес в России учится делать не только скучные проекты по автоматизации бизнес-процессов, но и создавать IT-решения, способные помочь в борьбе с конкурентами. Например, проекты по предсказанию спроса, real-time offer management, оптимизации логистики, микротаргетированию. Такие сложные задачи отличаются от типовых внедрений CRM или выбора CMS. Надо иначе искать разработчиков, иначе мотивировать, думать об IT-архитектуре и методологии управления.

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

Темы

1. Рынок IT
2. Привлечение разработчиков
3. Выбор платформы и языка для разработки
4. Методологии управления IT-проектами
5. Создание IT-продукта
6. IT-архитектура
7. Современные возможности IT с примерами

1 Рынок IT

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

1.1 Российский рынок IT

Несколько цитат и моих комментариев к статье CNews100 крупнейших ИТ-компаний России:

• «На долю топ-20 приходится 77,9% совокупной выручки». Если компании забрали 80% выручки, то это означает и контроль бюджетов, и контроль разработчиков, сосредоточенных в десятке компаний. С этими компаниями вы будете конкурировать за разработчиков.
• «Анализ суммарной выручки CNews100 в отраслевом разрезе показывает, что в 2016 г. около четверти заказов его участники получили от государственного сектора». В России государство — одни из крупнейших заказчиков. Это означает, что четверть разработчиков в стране работает над государственными заказами. Это также означает, что бизнес в России или без средств для инвестирования в IT или ещё не увидел ценность инвестиций в IT. Оба этих фактора дадут фору компании, которая грамотно инвестирует в IT в ближайшее время.

Ещё одна цитата из статьи CNews100: Рубеж в триллион пройден – спасибо падению рубля «… в долларах падение [выручки] усилилось в два раза — на 31,16% в 2015 г. по сравнению с 15,32% в 2014». Выводы, которые стоит сделать:

1. В 2014 году курс рубля упал в два раза и ровно на столько упал доход в долларах российских IT-компаний. Это показывает на сколько IT в России замкнут внутри страны, т.е. зарабатывает только в рублях, а не в валюте. Замкнутость рынка ведет к тому, что внутри страны мало мировых экспертов, которых просто нечем занять.
2. Такое положение дел выгодно для местных заказчиков и работодателей, потому что IT в России дешевое по мировым меркам.
3. Российские IT-продукты и услуги не востребованы на мировом рынке. Видимо бизнес стартует недостаточно амбициозные проекты или не доводит проекты и услуги до мирового уровня. Оба варианта негативно влияют на уровень кадров в стране.
4. Две предыдущих проблемы вынуждают сервисные компании (аутсорсеры) ориентироваться на международный рынок. Внутренние заказчики становятся неконкурентоспособными по деньгам и интересным проектам. Это значит, что даже найти профессионального подрядчика непросто.
5. Если стартовать амбициозный проект, то вы выгодно выделитесь на фоне типовых задач и привлечёте сильных разработчиков.

Получается, что в России не много продуктов и услуг мирового уровня. Госсектор не показывает эффективности при заказе и разработке ПО, поэтому экспертиза мирового уровня там накапливается медленно. Это влияет на качество разработчиков, уровень зарплат и развитие IT-сообщества. Чтобы пообщаться с экспертами мирового уровня или привлечь этих экспертов в проект, скорее всего придется выехать за пределы страны.

Более подробные цифры и выводы можно прочитать исследовании РУССОФТ Тринадцатое ежегодное исследование российской индустрии экспортной разработки программного обеспечения.

1.2 Действия правительства РФ

Минкомсвязи еще больше замыкает развитие на внутреннем рынке. В 2014 году Николай Никифоров заявил Минкомсвязи хочет увеличить количество программистов в России с 350 тыс до 1 млн, две цитаты:

• «Мы готовим комплекс мер, чтобы шаг за шагом, год за годом поддержать развитие и становление целой отрасли импортозамещающего программного обеспечения. Это небыстрый путь, который займет три года, по некоторым направлениям — 5-7лет». Вкладывать деньги в создавать отечественное ПО при глобальном IT-рынке мне кажется странной идеей.
• «Сейчас в России — всего 350 тысяч высококвалифицированных ИТ-специалистов, и работа министерства нацелена на то, чтобы в ближайшее время серьезно изменить этот показатель». Прошло три года, на дворе 2017 год, ситуация с разработчиками не изменилась. Я, как преподаватель с шестилетним стажем в двух ВУЗах на IT-специальностях, могу сказать, что пока ничего не предвещает прорыва.

Маcло в огонь подливает то, что государство ведет неоднозначный курс на контроль интернета внутри страны. Подробней в интервью Герман Клименко: «Нам всего-навсего осталась одна большая история — это деанонимизация».

1.3 Миграция разработчиков

На описанную ситуацию разработчики резонно отвечают миграцией из страны. Не массовой, но непрерывной и стабильной Немного о миграции ИТ-специалистов:

1. Мотивация переезда полностью совпала с причинами перемещения внутри РФ: заработная плата (54%), работа по профессии (47%), интересные проекты и карьерные перспективы (43%). Мы уже рассмотрели почему в России не всегда возможно реализовать эти две потребности.
2. Самыми популярными направлениями миграции оказались США (13,5%) и Германия (11,4%), за которыми следуют Австралия (9,2%), Канада (8,1%), Великобритания (7,6%) и Испания (5,4%). Страны со стабильной экономикой, присутствием мировых IT-лидеров, большими коммерческими бюджетами на IT-продукты.
3. Наиболее привлекательными регионами для переезда внутри страны были названы: Москва (29,2%), Санкт-Петербург (27,7%) и Краснодарский край (11,3%). Внутри страны тоже происходит миграция из регионов в столицы. Дальше из столицы разработчики мигрируют на Запад. Получаем типовой пусть Регион → [Столица] → Запад. Для владельцев бизнеса это создаёт вызов — удержание разработчиков в компании. Дальше рассмотрим, как это сделать.

Российские IT-компании открывают филиалы в Европе и США, чтобы разработчики оставались в компании, но работали в комфортной стране. Кроме этого преследуется цель снизить риск из-за санкций и нестабильной ситуации в стране. Подробнее в статье о вывозе программистов Luxoft перевез 536 инженеров из России и с Украины и интервью с СЕО компании JetBrains Глава компании JetBrains: у программистов неудачный имидж. Моя компания, например, разрешает разработчикам работать из любой точки планеты, у нас уже есть примеры переездов.

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

1.4 Рынок IT в целом

В целом для IT в данный момент характерно:

1. Максимум открытости, минимум бюрократии. IT-компании стараются убирать то, что мешает разработчикам творить: создают комфортные офисы, отказываются от дресс-кода, убирают ненужную бюрократию.
2. Результат напрямую зависит от уровня разработчиков. Только сильные айтишники делают крутые продукты. К сожалению, обезьяны разработчики среднего уровня не напишут сложный проект. Подробнее в статье «Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения»

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

• Техническая культура выше. В IT-компании адаптированы инженерные практики, идет отслеживание моды на языки, платформы и архитектуру. Новое и эффективное быстро берётся на вооружение.
• Новые технологии. Когда вокруг технари, то легче договорится и обосновать переход на новую технологию, архитектуру или платформу.
• Выше концентрация айтишников-единомышленников. В среде, где разработчика окружают такие же разработчики, профессиональный рост ускоряется. В обычной компании разработчик «прикреплён», например, к бухгалтерии, которую автоматизирует. Для него заказчик и собеседник — бухгалтер за стенкой, которая приходит и рассказывает какие кнопки добавить.

Посмотрите как один из крупнейших банков страны формулирует призыв к разработчикам Встреча с CIO банка «Открытие» Кириллом Меньшовым: «Хорошая новость для любителей рвать шаблоны и разрушать мифы: ИТ-специалист может найти интересную работу не только в технологической корпорации...».

Если банку Открытие приходится объяснять разработчикам, что в компании найдутся амбициозные задачи, то остальным участникам рынка стоит задуматься, как по-новому позиционировать себя для разработчиков.

2 Привлечение разработчиков

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

1. Станьте IT-компанией. Например, первый зампред Сбербанка в интервью на РКБ заявил, что Сбербанк теперь IT-компаний с банковской лицензией. При переходе от классической к технической компании сложнее всего изменить культуру, об этом подробнее ниже.
2. Стартовать интересные проекты. Интересные значит масштабные и дерзкие. Предприниматели должны идти дальше покупки CRM или автоматизации документооборота. В разделе Современные возможности IT с примерами рассмотрим несколько проектов, которые вдохновляют меня.
3. Делать проекты на новых технологиях и подходах. Будьте современны. Не стоит заставлять работать с FoxPro только потому, что вы в него верите. Дайте разработчикам сделать выбор. О том как сделать выбор расскажу в разделе Выбор платформы и языка для разработки.
4. Будьте заметными для разработчиков. Вдохновляйте целями компании и рассказывайте о планах. Для это подойдет спонсорство на конференциях, выступления на конференциях, статьи на Хабр или на VC.ru.
5. Вкладывайте силы в ключевую конкурентную компетенцию. Если вы купили и внедрили 1С, то это никак не изменило расстановку сил на рынке. Конкуренты купят 1С, и вы окажетесь с ними на равных. Делайте проекты, которые выделяют вас на рынке, такие проекты привлекают разработчиков.
6. Если у вас бедный, но перспективный стартап, предлагайте процент бизнеса и вдохновляйте. Предлагайте разработчиками акции или долю в бизнесе. Это типовой подход для IT-стартапов.

2.1 Воспитайте инженерную культуру

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

Если организацию представить в виде пирамидки, то культура — тугая резинка вокруг пирамидки. Вы сдвигаете одну из частей пирамиды, например, делаете процессы более «гибкими». Резинка натягивается и со временем аккуратно возвращает процессы на прежнее место:

Подробнее о подходах к изменению культуры в статье Culture is a rubber band around your organization.

3 Выбор платформы и языка для разработки

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

3.1 Выбор платформы

Есть базовые требования, которые вы можете проверить при выборе платформы:

1. Открытость исходного кода. Желательно, чтобы вы получили исходный код платформы вместе с покупкой лицензии. У вас не будет прав модифицировать и продавать этот код, но айтишники в компании смогут лучше понять устройство платформы.
2. Поддержка различных СУБД, очередей, облаков и т.п. Разнообразие поддерживаемых инструментов даст вам возможность выбрать правильный инструмент для конкретной задачи. Например, если платформа работает только с MSSQL или только с Oracle, то это должно вызвать вопросы.
3. Разнообразие способов интеграции. Платформа в итоге будет встроена в инфраструктуру компании и начнет принимать и отдавать данные другим система. Поэтому гибкость интеграции критична. Как минимум должна быть поддержка REST API и асинхронных взаимодействий через очередь сообщений или push-уведомлений. Подробнее о шаблонах интеграции в статье Integration Patterns: актуальные инструменты и о современных способах интеграции в статье Clouds, iPaaS, Citizen Integrator and Why India’s Outsourcing Is Losing Money.
4. Поддержка кода сообществом. В идеале, исходный код платформы должен быть выложен в Open Source и развиваться сообществом разработчиков. Такая открытость дает высокую скорость разработки и меньшую зависимость от вендора.
5. Наличие прозрачного SLA на тех. поддержку. Без этого пункта платформа не может использоваться в реальном бизнесе, иначе высок риск остаться один на один с проблемами выбранной платформы.

Есть набор более общих принципов:

1. Специализация важна. Например, 1С не стоит использовать для создания веб-проекта, как и Perl не стоит брать для автоматизации бухгалтерии. Каждый инструмент хорош для конкретной задачи. Теоретически хостинг для картинок реализуем на SAP, но это будет против природы вещей, и вы затратите лишние усилия на разработку и поддержку.
   Это также означает, что не стоит вкладывать деньги в дописывание коробочных решений. Например, BPM Online (1С, SAP или другая коробка) оправдывает вложения, если вы используете функции «из коробки». Если в коробке нет нужных функций, то вам придется дописывать их самостоятельно. При таком подходе платформа не добавит ценности, а только привяжет код, который вы сами написали, к своему движку. Лучше найдите готовое решение в другой коробке и грамотно интегрируйте системы.
2. Учитывайте функциональные и нефункциональные требования. Например, если требуется отклик в несколько миллисекунд, то не стоит брать CMS, потому что её тяжело оптимизировать по скорости. Если нужна работа на мобильных устройствах, то ищите продукты с родной поддержкой мобильных браузеров, чтобы не пришлось решать проблемы с мобильными через «костыли».
3. Выбирайте с экспертом. Если вы не айтишник со стажем, скорее всего опытные продавцы IT-продуктов сумеют продать вам что-то дорогое и ненужное. Вам будет сложно отличить маркетинговые ловушки от полезных функций. Найдите того, кто разбирается, и поручите ему выбор платформы.

3.2 Выбор языка программирования

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

Если у вас есть грамотные PHP-разработчики, которые готовы стартовать разработку Minimum Viable Product (MVP), значит делайте MVP на PHP. Не важно, что вы фанат Java. Потом найдете команду Java-программистов. Аналогично, если разработчики знают только mysql, а вы слышали, что postgresql круче — выбирайте mysql, потому что прямо сейчас можно сделать MVP на mysql и быстрее получить обратную связь от рынка. С первых заработанных денег вы перепишите проект на любимые технологии. Параллельно ищите разработчиков на технологиях, которые вам больше нравятся, а пока используйте что есть.

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

Доступность разработчиков на рынке. Проверяется очень просто. Заходите на hh.ru и ищите резюме по словам PHP, Java и т.д. Смотрите на цифру открытых резюме. Вы сразу заметите, что разработчиков на JavaScript — 94 120, а на Kotlin — 420. Чем больше доступных разработчиков, тем больше шансов найти нормальных кандидатов за приемлемое время и приемлемые деньги.

Популярность на stackoverflow. Идете на stackoverflow в раздел тэгов. Это популярная база с вопросами-ответами для разработчиков. Чем больше цифра рядом с тэгом, тем он популярней. Например, по языку C# задали 1 120 0000 вопросов, а по Lotus Notes всего 2 700. Это значит, что при выборе Lotus Notes вы остаетесь один на один с их тех. поддержкой, а при выборе C# вы найдёте ответ почти на любой вопрос.

Популярность на TIOBE. Индекс TIOBE основан на популярности поисковых запросов. По-моему, он отражает реальное положение дел.

Популярность языка в сообществе Open Source. Показывает на каких языках пишут разработчики, которые вкладывают силы в разработку Open Source. Информация собирается на сайте https://madnight.github.io/githut.

Эти четыре критерия удобны для поверхностной оценки непрофессионалом. Разносторонний анализ и выбор языка сделает только IT-архитектор или опытный разработчик. При выборе учитывается текущая инфраструктура, предстоящие задачи, план развития продукта и компании и т.д.

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

1. Найти сайты крупных международных и российских конференции и связаться со спикерами. Они охотно отвечают на вопросы, проверил на своем опыте. Например, GOTO и AgileDays.
2. Пойти в профессиональные сообщества в соц. сетях и связаться с лидерами или активными участниками. Скорее всего этим людям не всё равно, они болеют за профессию, поэтому есть шанс вовлечь их в решение своих проблем. Например, Архитектура ПО и Agile Russia.
3. Сделать поиск по сетям с профессиональными контактами на подобие LinkedIn. Находите там нужного человека, пишите ему в личные сообщения и общаетесь. Например, меня так находили не один раз и привлекали в качестве консультанта.
4. Банально — спросите рекомендации у коллег, которые получили позитивный опыт при работе с конкретной компанией или человеком. Хорошего айтишника, как хорошего врача, аккуратно передают из рук в руки.

4 Методологии управления IT-проектами

Подходы к управлению IT-проектами отличаются от управления проектами в материальном мире:

• IT — нематериальное. Если построить девятиэтажный дом, то в конце строительства никому не придет в голову раздвинуть пятый и шестой этажи, чтобы поместить между ними аквариум. А в программных продуктах такое происходит постоянно. Создание IT-продуктов часто начинают с высокой степенью неопределённости. Обычно не требуется писать исчерпывающее техническое задание, а достаточно описать ближайший небольшой релиз и дорожную карту.
• IT — интеллектуальный труд. Поэтому разработчиков нужно грамотно вовлекать в создание IT-продукта. Для начала изучения этой темы рекомендую книгу с говорящим названием Как пасти котов. Наставление для программистов, руководящих другими программистами.

4.1 Баланс между гибкостью и упорядоченностью

Существует множество разных подходов к управлению IT-проектами. Для упрощения я разделю все подходы на итерационно-инкрементальные и каскадные.

Процесс работы в стиле каскадной модели можно представить так:

1. Перед началом проекта выбирается цель — мешочек денег на рисунке.
2. До него прокладываются рельсы — делается аналитика, пишется техническое задание, подписываются контракты и т.д.
3. Когда рельсы проложены, запускаем проект в работу — паровозик поехал к цели.
4. Поменять цель сложно. Паровозик набирает инерцию, остановить его сложно. Если цель поменялась, то переложить рельсы сложно и дорого.

Процесс работы в итерационно-инкрементальном стиле можно представить так:

1. Перед началом проекта выбирается цель — небольшой мешочек денег на рисунке.
2. До него прокладываются примерная траектория — делается аналитика, например, по этому процессу.
3. Планируется работа первой итерации, в конце которой поставляется инкремент продукта — подарочек на схеме.
4. Команда продукта садится на самонаводящуюся ракету и летит к поставленной цели.
5. После нескольких поставок команда проекта может понять, что можно получить мешок денег большего размера, если изменить направление разработки — большой мешок денег внизу рисунка. Траектория перестраивается и следующие итерации идут по новой траектории.
6. Поставка инкремента происходит после каждой итерации. Обратная связь собирается в течение всего процесса разработки. Команда продукта имеет гибкую архитектуру, качественный код и готова менять продукта по ходу разработки бесконечное число раз.

Оба подхода имеют свои плюсы и минусы. Ни один из подходов нельзя назвать универсальным. При выборе между подходами можно оценивать пригодность подхода по схеме, которую я нарисовал по книге Balancing Agility and Discipline: A Guide for the Perplexed. Чем ближе характеристики вашего проекта к центру, тем более «гибкий» подход надо выбрать:

Еще один возможный критерий при выборе подхода к управлению — текущий этап жизненного цикла продукта. Об этом подробно рассказал Асхат Уразбаев в выступлении Как сохранить гибкость бизнеса, Agile Days 2017. На стадии зрелости стоит выбирать более формализованные подходы, а на стадиях создания и роста более гибкие:

4.2 Agile — это культура

Вокруг Agile сформировалось много мифов и легенд. Для начала давайте посмотрим, почему стоит внимательно присмотреться к этому подходу. Рекомендую посмотреть видео Греф про судьбу России и Agile подходах из IT — нефтяной век закончился. Цитаты из видео:

• «Мы сделали 27 000 изменений платформы за год. Amazon делает 10 000 изменений в день. Мы опаздываем, долгий time to market»
• «Те, кто не освоит Agile сегодня, будет лузерами завтра»

Весь «agile» описан в манифесте гибкой разработки ПО. Он состоит из четырех ценностей и двенадцати принципов. Обратите внимание на то, что обычно упускают из вида:

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

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

Крупные компании в России и по всему миру пытаются внедрить у себя Agile, но мало у кого получается. Причина в том, что Agile это не набор инструментов, а культура, которая меняется тяжело. Моя практика внедрений Agile в компаниях и практика коллег показывает, что только 3-10% сотрудников готовы менять свою культуру. Остальные либо не хотят, либо не способны к изменениям. Поэтому, если вы решили внедрить Agile, то проще всего начинать с чистого листа. Если такой вариант не возможен, то ищите и нанимайте как можно больше новых людей, которые уже разделяют ценности и принципы гибкой разработки.

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

Материалы, с которых можно начать изучение Agile:

• Видео Гибкое управление продуктом в двух словах.
• Spotify Engineering Culture, часть 1 и часть 2.
• Разные вариации манифеста гибкой разработки и другие популярные манифесты Подборка манифестов из мира IT.
• The Scrum Guide — свод всех правил Scrum.
• Книга о Scrum Scrum: The Art of Doing Twice the Work in Half the Time.
• 11-й ежегодный отчет State of Agile — исследование State of Agile проводится компанией VersionOne уже 11-й год среди компаний по всему миру и охватывает все основные аспекты применения Agile.

5 Создание IT-продукта

Прежде чем создавать IT-продукт, выберите цель и подход для вложения денег:

1. Если есть готовое — купите. Для решения типовых задач бизнеса, которые не относятся к вашей ключевой компетенции, купите готовое решение. Например, если у вас курьерская компания и вы учитесь оптимизировать логистику, то не надо создавать собственную бухгалтерскую систему. Лучше купите 1С для бухгалтерии, а деньги и силы вложите в логистику.
2. Отдайте на аутсорс вторичное. Например, рутинные задачи автоматизации. Если готовая система из коробки вам не подходит или ее надо внедрять, то закажите эту работу на аутсорсе. Помните, что если вы купили крутую CRM, то это не конкурентное преимущество, потому что любой игрок на рынке купит эту CRM.
3. Создайте уникальное, то, что отделит вас от конкурентов. Например, мощную систему real-time offer management, которая сделает покупателей счастливыми, а вас богатыми.

Если вы дошли до п.3 и поняли, во что конкретно хотите вложить деньги, то теперь надо дёшево проверить идею и посчитать экономику.

5.1 Убить идею дёшево

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

Возможно так и случится. А возможно мы ошибаемся, и никто не заплатит за будущий продукт. Чтобы быстро проверить идею и не потерять деньги на галлюцинациях, рекомендую изучить книгу Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели. Коротко опишу шаги, которые надо пройти:

1. Сначала «продайте» идею пользователям. Убедитесь, что у пользователей есть боль и эту боль снимает ваш продукт. Сделайте эту проверку без разработки ПО. В статье о том, как запускался Dropbox, вы найдете пример такого подхода: «To avoid the risk of waking up after years of development with a product nobody wanted, Drew did something unexpectedly easy: he made a video». Важно проверять идею не на ваших родных и друзьях, а на максимально широком круге людей.
2. Посчитать экономику проекта. Об этом подробнее расскажу ниже.
3. Решите убить проект или вложиться. В идеале, надо сразу понять есть ли отклик рынка на продукт. Если отклика нет, то не вкладывать деньги в MVP, а убить проект. Если отклик есть и экономика сходится, то ищите способы кратного роста и, если надо, достойных инвесторов.

Есть еще один вариант, как распорядится своими деньгами и временем. Называется «Прыжок веры», как в Assassin's Creed. Вы ничего не проверяете, а доверяетесь своему чутью и вкладываете в идею без проверки. Такой вариант имеет права на жизнь, но риски выше, чем у варианта с проверкой рынка и расчетом экономики.

5.2 Экономика стартапа и метрики

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

Илья Красинский из ФРИИ один из немногих в нашей стране, кто рассказывает доступным языком как правильно считать экономику. Рекомендую начать с видео HSE{sun}: Экономика стартапа и метрики: как помочь проекту найти цель и эффективно к ней идти и пройтись по его выступлениям.

5.3 Growth hacking

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

Для вдохновения рекомендую прочитать историю о том, как вырос проект Airbnb. У них не было базы данных по недвижимости. Поэтому Airbnb решили позаимствовать базу с другого популярного сайта. Подробнее читайте в статье Airbnb: The Growth Story You Didn't Know.

На русском языке о Growth hacking пишут, например, на VC.ru.

5.4 Процесс разработки

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

1. Impact Mapping — карта целей и бизнес-гипотез.
2. Customer Journey Mapping — карта контактов пользователей с системой, артефактов и барьеров.
3. User Story Mapping — двумерная карта-план по реализации пользовательских сценариев.

Эти три инструмента — визуальные средства коммуникации внутри продуктовой команды. Я не рекомендую писать технические задания. Более подробно об этом в статьях Техническое задание как база знаний о проекте и Откровенное общение с заказчиком.

Желательно поставку новых фич сделать через короткие итерации длиной в одну неделю или в один день или один час. Чем выше уровень компетенций в команде, тем выше скорость поставки.

При таком подходе процесс разработки превращается в непрерывную проверку гипотез:

Подробное описание процесса в статье с видео и слайдами Пять самых важных составляющих процесса выпуска проектов, Agile Days 2016.

5.5 Экономика экосистем

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

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

6 IT-архитектура

Чтобы понять какая архитектура в моде и почему так произошло, стоит увидеть, как развивались требования бизнеса и предложение со стороны IT:

• Сначала было много маленьких независимых систем. До конца 80-х годов превалировал подход делать под каждую задачу отдельную программу. Таких программ было много, они были слабо связаны. В какой-то момент бизнес понял, что накладные расходы при таком подходе слишком высокие.
• Тогда появились большие ERP. Эти системы вобрали в себя бизнес-функции и дали «единое окно» для бизнеса. Например, вы ставите SAP на предприятии, и пользователи работают в одной программе. Больше ничего покупать и ставить не надо. Такой подход занял основное место при проектировании систем на пару десятков лет. С развитием облаков, культуры DevOps и культуры коротких релизов, пришло понимание, что огромные монолиты не могут развиваться достаточно быстро. Часто они тормозят бизнес.
• Сейчас развивается идея микросервисов. Этот подход сохраняет идею «единого окна», но дробит серверную часть на маленькие независимые сервисы.

Почему стоит присмотреться к микросервисной архитектуре:

1. Быстрая поставка новых фич. Отдельные части вашего сервиса (сайта, мобильного приложения, ...) можно обновлять независимо от других частей системы. Скорость поставки новых фич у разных частей системы будет своя и не придется ждать одновременного релиза.
2. Независимая разработка. Каждый сервис или набор сервисов развивается независимым кросс-функциональными командами. Это снижает критичность bus factor и повышает экспертизу команд.
3. Разнородные среды и языки. Под каждый сервис можно выбрать лучшее решение, а не идти на компромиссы, как обычно бывает при единой платформе.
4. Масштабирование. Сервисы нагружены по-разному, в разное время у них бывают пики. Поэтому каждый сервис сам заботится о своем масштабировании, что в итоге приводит к экономии ресурсов и более оптимальным бюджетам на «железо».

Более подробно о микросервисах, когда их стоит использовать и когда не стоит, какие сложности возникают при внедрении, посмотрите в видео Microsoft Dev School — Микросервисы, чистый PaaS и конкурс мисс Россия и в презентации Бизнес-гибкость через микросервисную архитектуру, Agile Days 2017.

7 Современные возможности IT с примерами

IT быстро растет. Развиваются подходы к машинному обучению и искусственному интеллекту. Я перечислю несколько проектов, которые меня вдохновляют:

1. Amazon предсказывает где и что купят, загружает этой продукцией грузовики и отправляет их к месту покупки. При заказе на Amazon клиенты могут получить посылку в течение часа. Подробности в статье Why Amazon's Anticipatory Shipping Is Pure Genius.
2. Для определения личностных характеристик водителя Uber использует Microsoft Cognitive Services. Подробности в описании Uber boosts platform security with the Face API, part of Microsoft Cognitive Services.
3. По фотографии в соц. сети определяли является девушка интровертом или экстравертом. Экстравертам показывали рекламу косметики в стиле «будь самой крутой на вечеринке», а интровертам показывали рекламу в стиле «подчеркни свою индивидуальность». При таком подходе к микротаргетированию конверсия рекламы повысилась от 50 до 100%. Подробности этого и других кейсов в выступлении Михала Косински Открытая лекция о взаимодействии человека и искусственного интеллекта.
4. Siemens заменила менеджеров компьютерной программой.
5. AI научился предсказывать преступные наклонности по фото. Лучше других показала себя свёрточная нейронная сеть, точность предсказаний которой достигла почти 90 процентов.

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

Автор: AlexanderByndyu

Источник