Publications / Fail review: о проблемах в разработке и методах их решения

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

Слово «стартап» сейчас очень модное. И среди ваших друзей и знакомых точно есть кто-то, кто уже пробовал запустить свой проект или даже предлагал вам стать ко-фаундером. Такая же история произошла и с моим товарищем. Пришёл к нему потенциальный клиент и попросил разработать, ну, скажем, клон Facebook. Идея вроде неплохая. Выход на IPO спланирован, список, куда потратить миллиардные доходы, уже написан. Осталось дело за малым — заказать софт, который и позволит в считанные дни заработать эти самые миллиарды. Инвестиции в новый стартап клиент тоже подготовил — гигантскую сумму в 5000 евро. Ударили по рукам, закипела работа.

Вот только убийцу Facebook сделать не удалось ни через планируемые 3 месяца, ни через полгода. А когда для ускорения процесса разработки была привлечена дополнительная команда, и клиенту был выставлен счёт за проделанные работы — выдержке его пришёл конец. Мало того, что ожидаемые миллиарды не появились, Forbes не стал брать интервью, так ещё и затраты оказались в несколько раз выше, чем планировались. И если для тех, кто знаком cо спецификой рынка ИТ, данная история — одна из тысячи подобных, и каждый, кто довольно давно работает в этом бизнесе, понимает, что на один выстреливший продукт может приходится до сотни неудачных, то для нового человека это может быть шоком. Ведь именно он автор гениальной идеи, и именно он заработает завтра свой первый миллиард.

Выводов из этой истории два:

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

Вывод второй — не работайте с людьми, которые не осознают своих желаний. Мало прийти в компанию по разработке ПО и сказать: «Я хочу второй Facebook». Клиент должен понимать законы индустрии, в которую он входит, осознавать, что и для чего ему нужно.

История № 2: Не гонитесь за большим количеством фич

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

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

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

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

Вывод: нельзя сказать, что мы особо много заработали на этом проекте, но опыт (который, как известно, дороже денег) мы получили — не нужно гнаться за количеством фич в своём продукте. Лучше сделать несколько или даже одну, но пусть она работает хорошо.