Pull to refresh

Как делать нужные людям проекты, или почему не взлетают стартапы

Reading time 9 min
Views 8.6K
Сегодня на практических примерах мы разберем два мифа в управлении проектами, в том числе в разработке стартапов:
1. То, что лучший и единственный способ сделать успешный стартап — сделать такой, который решает задачи, хорошо знакомые создателю в повседневной жизни.
2. То, что существует автономизация бизнеса, когда проект можно довести до некоторой точки и больше ничего не делать, а потом он просто будет на автомате приносить деньги.



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


1. Как важно увидеть проект глазами пользователя


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

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

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

Кстати, о важности логики говорит и Сергей Галицкий (кто не знает — миллиардер, создал с нуля (!) розничную сеть «Магнит») в программе Бизнес-секреты, и мы этой темы еще коснемся. В целом отмечу, что мне нравится высказывания Фрица Моргена, который не стал делить людей на логиков и интуитов, а высказал предположение, что у грамотных людей логика и интуиция работают последовательно, в одном цикле, сменяя друг друга.

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

Можно устранить ошибку, просто вовремя задумавшись
Можно устранить ошибку, просто вовремя задумавшись

Теперь — практический пример. Говорят, что чем раньше будет обнаружена ошибка — тем меньше стоимость ее устранения, и разница между исправлением в прототипе интерфейса и в релизе тысячи копий может достигать 1000 раз (в абсолютном выражении — миллионов долларов). Но о чем нередко забывают — что ошибку можно обнаружить не только на стадии прототипирования (проектирования интерфейса), но еще раньше — на стадии мышления.

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

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

Кажется, она опять попала в расширенный поиск
Кажется, она опять попала в расширенный поиск

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

Теперь вернемся к планированию итерации. Теперь вы знаете, что расширенный поиск — это будут две недели потерянного времени. В прямом денежном выражении — 10*N*S(i), где N — число программистов, S(i) — зарплата каждого за рабочий день. Например, для трех программистов с днем стоимостью $100 это будет 10x3x100 = $3000, то есть около 100 000 рублей! А если у вас еще есть конкуренты, которые за эти две недели сделают конкурентное преимущество — то потери будут несоизмеримо больше.

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

Таким образом, погружение в шкуру вашего пользователя дает вам:
1. Точное понимание важных задач в текущем моменте
2. Как следствие, возможность отсекать ненужный функционал еще на уровне обдумывания — если он не решает задач пользователя, его можно смело отсекать.


При этом мы не рассматриваем вопрос определения, кто же именно ваш пользователь — это выходит за рамки статьи, и, кстати, об этом же говорит мой любимый Потапенко — в 90% на вопрос «кто же ваш покупатель» звучит ответ «женщина от 30 до 50», что есть полная хуйня — то есть покупатель точно не определен.

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

2. Как правильно общаться с программистами


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

Но почему же повсюду мы слышим эти обвинения в наш адрес? Да потому, что хороших управленцев в России не просто мало — их вообще, считай, нет. А именно от руководителя проектом зависит работа программиста. Разберем последовательно все проблемы.

Первое — программисту неинтересно. Это может быть либо в случае, когда человек занимается не своим делом (пришел из вебмастеров, работает тупо за деньги, и так далее), и ему вообще на все насрать, лишь бы платили. Но это — редкость. Второе — это руководитель не тратит время на вовлечение программиста, не показывает ему, что в проекте интересного, как важно то, что делается. Не дает фидбэк от пользователей. Чаще всего просто дает ТЗ и говорит — сделай так, как я сказал, и все. В то же время, если программисту объяснить проект с точки зрения пользователя, показать, какие вкусные и важные вещи делаются, поделиться с ним получаемой благодарностью — даже просто лог из аськи переслать «какой клевый раздел сделали!» от пользователя — программист начинает чувствовать свою активную роль в проекте, и гораздо лучше работает. Нужно просто делиться правдой и понимать важность вовлечение.

Второе — неработающий функционал. То же самое — если бы руководитель объяснял программисту, приучал его смотреть с точки зрения пользователя, выделял важные моменты, рассказывал логику — программист бы сам проверял, как все работает, и в 90% случаев тестировать не нужно было бы. По словам Макконнелла, мотивированный и немотивированный программисты отличаются в скорости до десяти раз.

Важность точного донесения информации до других участников проекта нельзя недооценивать
Важность точного донесения информации до других участников проекта нельзя недооценивать

Еще один момент — постановка задачи. Своих руководителей проектов я учу ставить задачи по пунктам, так, чтобы программисту было легко понять задачу. Критерий один — после прочтения задачи у программиста не должно возникать вопросов. Вообще. При этом я стремлюсь, чтобы постановка задачи была разделена минимум на два пункта — абстракцию и реализацию (Принцип инверсии зависимостей рулит и тут). Например, есть задача сделать таблицу с фильтрами, и дана верстка. Сначала нужно написать логику работы, без привязки к визуальной части. Алгоритм словами, входные данные и выходные, рассмотреть граничные значения, дать пример работы алгоритма на живых, боевых данных (то есть что на вход, и что на выходе должно получиться). Затем — описать спецификацию верстки, какой элемент какую функцию выполняет и как связан с другими.

По сути дела, описывать задачу нужно на языке программиста, и чем вы ближе по мышлению к техническому — тем проще вам будет. Идеальный вариант — это UML диаграммы (типа диаграммы последовательностей), которые легко можно рисовать от руки и быстро сканить (сканер стоит $100 и окупается в первую неделю, экономя в месяц вам часы разговоров — 90% информации передается визуально и лишь около 9-10% — на слух).

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

Дальше, нереальные сроки. Это также легко решается на уровне мышления. Прежде чем вам пришла мысль поставить задачу, нужно спросить себя, задать несколько вопросов:
1. Это можно не делать? Насколько можно отложить обдумывание, проработку этой задачи (проработкой я называю превращение мысли в точную постановку для программиста)?
2. Как это можно сделать проще?
3. Какие есть альтернативные варианты решения вопроса (вплоть до административных)?

Если выбор сделан, нужно работать с программистом. Для начала обсудите задачу голосом, спросите время. Допустим, в случае таблицы с фильтрами вы услышали — 23 часа, а нужно сделать задачу на 4 часа. У вас три фильтра — выпадающие списки по стране, курорту и дате, и таблица выводит записи. Просите программиста расписать этапы задачи, даете полчаса подумать, получаете список:
— словарик курортов, стран на уровне базы с админкой — 8 часов
— календарик для выбора даты — 1 час
— сортировки в таблице — 4 часа
— выборка из БД и вывод из таблицы — 2 часа
— пейджинг — 4 часа
— фильтр по дате, стране, курорту — 4 часа

Задавая наводящие вопросы по непонятным пунктом, помня про реально важный функционал, а также прикидывая, как будет выглядеть задач на живых данных, говорите делать следующие этапы
1. Так как записей будет не более 100, пейджинг не нужен
2. Так как будут фильтры и записей немного, сортировки (которые программист легко сам включит в список) не нужны
3. Так как реально стран будет две, курортов меньше 10, а смотреть в большей части случаев записи нужно за вчера — говорите сделать для начала прямо хардкодом (массивом в коде) страны и курорты и вчерашний день, без календарика
4. Зная, что программист в среднем оптимистичен на 100%, говорите ему, что самым важным является просто вывод данных из базы в виде простой таблицы, которую можно набросать ему самому на 5 минут на голом HTML (экономим время, верстку прикрутим потом), и даете 2 часа. В итоге за 4 часа он сделает то, что вам нужно.
5. Заверяете его, что будет дано время на рефакторинг.

И таким образом — с каждой задачей, пока вы не получите на 80-90% то, что вам нужно. Тогда переключаетесь на другого программиста и другую задачу, а текущему даете отрефакторить. Здесь все в выигрыше: и вы сначала, очень быстро делаете несколько итераций на живых данных, и получаете конечный вид и логику системы, и программист — он не будет писать долго то, что потом придется переделывать (ведь вы еще не сделали микроитерации, чтобы точно понять, как нужно правильно), а говнокодом (нужно иногда продавить быстрый вариант, показать выгоду) сделает пару итераций, получит очень точный вариант задачи, и сможет ее отрефакторить, имея уже точное понимание, как там все устроено.

Со временем программисты будут мудрее и опытнее, и будут в зависимости от стадии задачи (разработка нового функционала, или старт проекта) выбирать стратегию — быстрый раш с говнокодом и микроитерациями + рефакторинг, или сразу уточнение требований и точная реализация (если гнаться уже некуда, идет допилка проекта)

Все вышеописанное — это, конечно, микроменеджмент, но это позволяет делать релизы каждый день на ранних стадиях проекта и на 80-90% точный функционал. Если вы знаете подход, который лучше позволяет на первом этапе действовать — опишите в комментариях.

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



Теперь о втором мифе. Дело в том, что любая живая сущность движется, эволюционирует. Это значит, у любого проекта появляются конкуренты. И если вы оставили проект в нетронутом состоянии — пока вы находитесь на одном проекте, другие движутся вперед. В том числе — и ваши пользователи, которые начинают использовать функционал вовсе не так, как вы задумывали. И если вовремя не вмешаться — часто нужно все переделывать сначала.

Иногда проекту штаны становятся уже не по размеру
Иногда проекту штаны становятся уже не по размеру

Пример — допустим, у вас есть система управления проектами на основе Mantis. Там есть просто главный проект, и подпроект. Вы когда-то заложили такую иерархию и не меняли ее. Идут годы. Люди станут добавлять в подпроекты, когда число проектов сильно вырастет, уже и другие сущности — туда будут добавлять новые разделы, над которыми идет разработка. Возможно, в качестве проекта будет добавлена вообще какая-то категория типа «Клиентские сайты». И в итоге, когда вы дойдете до проблемы, вы обнаружите, что у вас в структуре из простого дерева заложено множество сущностей: категория, проект, раздел, связь с клиентом, связь с определенным отделом, и так далее. То есть структура не изменялась, в то время как живые данные — основа любого проекта — эволюционировали, и переросли свой каркас.

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

Подводим итоги


1. Самое важное — правильно мыслить. Уметь взглянуть на проект глазами своего пользователя и тем самым понимать реально важные задачи, и то, как эти задачи нужно сделать. Стартапы не взлетают потому, что делают неправильный функционал, не нужный никому, и теряют деньги и время.
2. На 90% проблемы в проектах — ошибки в следствие неверного менеджмента.
3. Правильная мотивация, вовлечение программиста, проработанная постановка задач и плотная работа с программистом по определенной методологии позволяют ускорить до 10 раз и делать на 80-90% нужный функционал точно в срок, при этом выделяя время на рефакторинг для программиста
4. Любой проект нужно развивать, чтобы он жил.

Желаю Вам удачи и предлагаю поделиться своим опытом в комментариях.

Кросспост в моем ЖЖ
Tags:
Hubs:
+46
Comments 48
Comments Comments 48

Articles