Как найти проблему

Не ищите идею — выберите области, где вы уже внутри

Забудьте про «перспективный рынок». Возьмите три-пять областей, которые вы знаете изнутри, и смотрите только в них.

У четверокурсника таких областей больше, чем ему кажется. Разработка со всем, что вокруг неё: ревью, сборки, тесты, дежурства. ИИ-инструменты в реальной работе — где они помогают, а где создают новую работу вместо старой. Учебный процесс: расписание, лабораторные, проекты, пересдачи. Университетская инфраструктура: пропуска, лаборатории, оборудование, справки. Ваша подработка или стажировка, где на ваших глазах каждый день происходят чужие офисные процессы. Любое хобби с живым сообществом — спорт, музыка, настолки, видео.

Всё это — места, где у вас есть преимущество, которого нет больше ни у кого в аудитории. Человек со стороны видит «так устроено». Вы видите «почему это до сих пор делают руками?». Пол Грэм называет это состоянием на переднем крае области: вы не столько ищете проблемы, сколько перестаёте их не замечать.

Заведите таблицу и начните её заполнять. Три колонки, никаких решений — только то, что вы наблюдали.

Ситуация	Что раздражает, долго или дорого	Как справляются сейчас
Сдача лабораторной	непонятно, принята она или нет	пишут старосте, староста пишет преподавателю
Запись на проект	реальная нагрузка видна только изнутри	спрашивают тех, кто был в прошлом году
Ревью пулл-реквеста	долго собирать контекст изменения	вручную сверяют задачу в трекере и историю коммитов
Расход на LLM в команде	непонятно, кто сколько потратил	раз в месяц смотрят биллинг глазами

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

Заведите журнал проблем

Две недели подряд записывайте всё, что попадает под такие формулировки:

• «опять приходится…»;
• «почему нельзя просто…»;
• «мы каждый раз вручную…»;
• «на это уходит часа два»;
• «для этого у нас отдельная табличка»;
• «мы написали свой скрипт, нормального инструмента нет».

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

Записывайте в тот же день. Проблема, замеченная в среду и не записанная, к пятнице превращается в «ну там было что-то неудобное».

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

Отличайте раздражение от дорогой проблемы

Раздражает многое. Платят за немногое. Прежде чем идти с проблемой дальше, оцените её по четырём шкалам от 1 до 5 и перемножьте оценки.

Оценка проблемы = частота × боль × цена × срочность. Частота — как часто это происходит. Боль — насколько мешает, когда происходит. Цена — во что обходится в деньгах, времени или риске. Срочность — что будет, если не решать ещё полгода.

Проблема	Частота	Боль	Цена	Срочность	Итого
Раз в год неудобно заполнять форму	1	2	1	1	2
Каждый день разработчики ждут сборку	5	4	4	4	320
Раз в месяц сверяют данные в четырёх системах руками	3	5	5	5	375

Метрика ненаучная, и спорить, четвёрка тут или тройка, бессмысленно. Формула нужна для одного: заставить сравнивать проблемы между собой, а не влюбляться в первую попавшуюся. Разница между 2 и 375 переживёт любые разногласия в оценках.

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

Формулируйте работу, а не функцию

Дальше нужен язык, на котором проблему нельзя перепутать с решением. Самый удобный — «работа, на которую нанимают», Jobs to be Done.

Вот как звучит подмена:

Пользователю нужен ИИ-календарь.

А вот та же ситуация, описанная честно:

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

Второе — работа. Первое — решение, которое притворилось потребностью и заодно избавило вас от необходимости в чём-либо разбираться.

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

Шаблон, которым удобно записывать:

Когда [ситуация], я хочу [действие], чтобы [результат].

Например:

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

Тот же способ думать вы уже применяли на квесте 1 «Биржа идей», когда заполняли карточку: кто, в какой ситуации, что не получается, почему я думаю, что это правда. Это не два разных бланка, а один и тот же вопрос с разных сторон.

Поговорите с людьми — и ничего не продавайте

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

Если бы было приложение, которое всё это делает автоматически, ты бы им пользовался?

Ответ будет «да», и он ничего не стоит. Люди вежливы, особенно с однокурсником, который явно воодушевлён своей затеей. К тому же гипотетическое будущее все описывают оптимистично: человек искренне верит, что начнёт бегать по утрам и пользоваться вашим сервисом. Конкретное прошлое устроено честнее — оно уже случилось.

Поэтому спрашивайте про прошлое. Пятнадцати минут хватает:

1. Расскажи, как ты сейчас делаешь X.
2. Когда делал в последний раз?
3. Покажи, если можно. (Экран, папка, таблица, переписка.)
4. Что было самым муторным?
5. Почему это вообще проблема?
6. Сколько времени ушло?
7. Что пробовал вместо этого?
8. Почему не подошло?
9. Кто решает, пользоваться этим или нет?
10. Во что эта история обходится сейчас?

Седьмой вопрос — самый сильный: что вы уже пытались сделать, чтобы это решить.

Ответ «ничего» — плохая новость. Значит, терпеть дешевле, чем чинить, и вашим инструментом займутся по остаточному принципу. Ответ «полгода платим за сервис, и он нас не устраивает» или «я написал скрипт, но он ломается каждый семестр» — хорошая: проблема уже стоит кому-то денег и времени.

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

Проверьте себя «мом-тестом»

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

Плохо:

Купили бы вы инструмент, который автоматически анализирует пулл-реквесты?

Хорошо:

Расскажи про последний тяжёлый пулл-реквест. Сколько шло ревью? Кто участвовал? Что тормозило?

Суть в том, чтобы спрашивать не мнение о вашей идее, а факты об их жизни. Мнение бесплатное, факты можно проверить.

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

Найдите пять человек с одной и той же проблемой

Одно наблюдение — это история из жизни. Повтор — уже закономерность.

«Я видел, как человек мучается с расписанием» и «семь старост независимо друг от друга описали один и тот же процесс почти одними словами» — утверждения разного веса, и второе стоит потраченных на него разговоров.

Сведите интервью в таблицу: в строках признаки проблемы, в столбцах люди. Заполняется быстро, смотрится безжалостно.

Признак	Аня	Борис	Вика	Глеб
Сверяет данные вручную	+	+	+	+
Тратит больше двух часов	+		+
Ведёт для этого таблицу	+	+	+
Готов платить или выделить время		+	+

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

Посмотрите, что люди уже нанимают вместо вас

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

Поэтому после вопроса «как вы решаете это сейчас?» задавайте второй:

А почему вы до сих пор пользуетесь именно этим?

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

Про главного конкурента забывать не стоит: это «ничего не делать». Он бесплатный, привычный, не требует внедрения и обучения. Ему проигрывают чаще, чем всем остальным вместе взятым.

Соберите портрет пользователя до того, как придумали продукт

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

Скажем, староста группы:

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

Боль: сообщение тонет в чате между мемами и обсуждением сдачи.

Боль: понять, кто прочитал, а кто нет, можно только спросив лично у каждого.

Выгода: за десять секунд видеть, до кого информация не дошла.

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

Проверьте проблему до того, как написали код

Самый недооценённый шаг из всех. «Я бы пользовался» ничего не стоит, поступок стоит. Между «у нас есть проблема» и «мы пишем код» помещается неделя дешёвых проверок.

• Дверь без комнаты. Одна страница с описанием и кнопкой, за кнопкой — форма «оставьте контакт». Считаете, сколько человек нажали.
• Ручной сервис. Никакой системы: «пришлите данные, я соберу отчёт руками и верну к вечеру». Если за отчётом пришли во второй и третий раз — проблема настоящая.
• Пилот с обязательством. «Мы решим это для вашей команды за две недели, с вас доступ и час в неделю на созвон». Плата не обязана быть деньгами: время и внимание — тоже цена, и её тоже жалко.
• Предварительная запись. Список из десяти человек, которые оставили контакт и ждут запуска.

Любой такой результат весит на защите больше, чем красивый макет. Макет показывает, что вы умеете рисовать. Список из десяти контактов показывает, что за пределами аудитории есть люди, которым это нужно.