
<TlDrBlock>

## Краткое содержание

1. [**Сложно выбрать подходящую команду разработчиков**](#неправильный-выбор-команды). Предложений хватает, но параметров, по которым вы должны сойтись много и они не простые.
1. [**Недооценка трудозатрат**](#неправильная-оценка-трудозатрат-и-ресурсов). Деньги закончатся раньше, чем продукт будет доделан.
1. [**Неправильное планирование**](#неправильное-разбиение-на-этапы). Cо старта начинают делать слишком сложную функциональность, вместо того чтобы выкатывать небольшие наработки и тестировать пользовательский отклик.
1. [**Размытие фокуса**](#размытие-фокуса). Начинали делать одно, в процессе приходило много идей, брались за них. В итоге от начальной идеи ушли далеко в сторону.
1. [**Запоздалый маркетинг**](#запоздалый-маркетинг).
   - **Не правильно**: сначала разработка, потом маркетинг
   - **Правильно**: разработка и маркетинг стартуют одновременно

</TlDrBlock>

## Введение

![](project_failure.png)

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

В информационное поле в основном попадают только истории успешных проектов. Тех, у кого получилось.

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

В статье мы формулируем **основные ошибки, допускаемые проектными командами**.

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

## Неправильный выбор команды

![](wrong-team.jpg)

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

На что обращать внимание при выборе подрядчика?

### Наличие специалистов с релевантным опытом и в достаточном количестве

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

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

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

### Коммуникабельность сотрудников и руководства

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

Если напряжение возникает в общений с одним сотрудником, попросите руководство заменить его. Если с несколькими сотрудниками – скорее всего стоит рассмотреть другие предложения.

### Цена услуги

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

Получите информацию о ставках со всех компаний, кого рассматриваете как подрядчика. Сравните цены. **Отсейте тех, чьи котировки сильно отличаются от среднего**.

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

**Высокая цена** не должна порождать чувство уверенности, гарантированности результата. Она должна быть оправдана объективными причинами. Например:

- **Крупная компания** с хорошим портфолио. Много сотрудников, много экспертизы. Так или иначе решат любую проблему. Окажут поддержку на длинном периоде.
- **Уникальная экспертиза**. Хорошо понимают нетривиальную бизнес область, для которой вы задумали проект. Объективно сделают работу в разы быстрее компаний, у которых нет экспертности.
- География. Если вы нашли компанию из западной Европы, то чек будет в 2-3 раза выше российского.

### Стабильность компании

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

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

### Репутация

Кто клиенты?

### Как избежать ошибки и выбрать правильную команду?

> - **Не лениться, и отправить свою заявку на разработку проекта как можно большему количеству компаний и провести первичные переговоры**.
>   На этом этапе, как ни странно, многие отсеются. Либо просто не ответят на заявку, либо ответят, что не могут сейчас заняться вашей задачей. Либо она будет для них сильно не профильной, либо не будет свободного ресурса.
> - **Получить коммерческие предложения**. На этом этапе также многие отсеются.
>   - Кто-то скажет, что для оценки недостаточно данных, нужна более детальная постановка. Это нормально, чаще всего действительно так. Но инвестор сможет оценить, как компания обрабатывает эту ситуацию. На сколько профессиональны и контактны менеджеры, проявляют ли интерес к проекту, понимают ли задачу и т.п.
>   - Кто-то попросит оплатить оценку проекта и составление КП. Бывают ситуации, когда имеет смысл выделение разработки технического задания или хотя бы
> - **Познакомиться с командой**, хотя бы с основными участниками. С остальными можно ознакомиться на уровне резюме. Здесь отсеются те, кто откажет с знакомстве с командой.
> - **Оценить стек технологий**, на котором подрядчик планирует реализовывать проект. Подрядчик > всегда будет предлагать тот набор технологий, под который у него есть достаточный набор специалистов. На другом он просто не сделает, т.к. нет людей. Проблема в том, что в некоторых ситуациях технологический стек может принципиально не подходить под вашу задачу. Большинство типов проектов достаточно толерантно к технологиям, но возможны ситуации, когда ошибка в этом вопросе может поставить крест на проекте.

## Неправильная оценка трудозатрат и ресурсов

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

Проблема в том, что земля глубже пяти сантиметров может оказаться слегка каменистой 👇.

![](trench-stones.png)

С IT проектами ситуация не лучше. При оценке неизбежно делается много **оптимистичных допущений**.

Основные причины недооценки требуемых ресурсов:

1. **Слабая проработка постановки**. _"Без ТЗ результат ХЗ"_, гласит народная мудрость. В половине заявок, приходящих к нам, постановка даётся на уровне одного абзаца текста. Ещё в 40% есть документ, в котором описывается бизнес идея. Этого недостаточно.
1. **Отсутствие коэффициента на риски**. Абсолютно всегда что-то пойдёт не так и займёт больше времени. Добавляйте к оценке вендоров 30%. Хороший вендор сделает это сам и в явном виде обозначит в КП.

### Как минимизировать ошибки при оценке трудозатрат

> - **Насторожиться, если подрядчик выдал вам оценку через несколько часов**. В зависимости от сложности проекта на качественную оценку может потребоваться несколько дней и масса уточняющих вопросов.
> - **Получить несколько независимых оценок**. Они никогда не совпадут точно, даже в пределах 20-30%-го отклонения, но дадут понимание порядка. А дополнительное обсуждение с оценивающим подрядчиком подсветят проблемы в постановке.
> - **Закладывать риски**. Просто умножьте полученные оценки на 1,5.

## Неправильное разбиение на этапы

Почему важно делать MVP

## Размытие фокуса

Начали делать одно, в процессе работы 👁️

## Запоздалый маркетинг

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

На наш взгляд это результат комбинации нескольких **психологических барьеров**:

- Продукт ещё не готов, неудобно показывать публично. Неудобно перед кем?
- Маркетинг – это совершенно отдельная от разработки продукта задача. Мало кто в него умеет и хочет. Людям с инженерным складом ума приятнее погрузиться в разработку. Там интересно и комфортно.

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

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

Кстати, блог можно вести чужими руками. И поверьте, это будет намного дешевле разработки даже MVP проекта.

Также важно понимать, что **эффект от любой маркетинговой активности будет сильно отложен во времени** ⏲️. Скажем, если вы начнёте вести тематический блог в расчёте на поисковый траффик, то не стоит ждать результатов раньше, чем через 2-3 месяца.

### Советы по маркетингу

> - Не воспринимайте маркетинг как что-то, что произойдёт само по себе, когда вы запустите продукт. **Не произойдёт**.
> - Начинайте маркетинговую активность как можно раньше
> - Если не знаете как это делать самостоятельно, наймите разбирающегося человека или компанию
> - Маркетинг не бесплатный. В зависимости от проекта он может требовать вложений на одном уровне с разработкой


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

Блог #управление проектами

Почему ваш IT проект скорее всего не взлетит

Последнее