Вы знаете, как устроено производство, как проходят заказы, как работают менеджеры, какие отчёты нужны директору. Это ваша экспертиза.
Я знаю, как задавать вопросы, чтобы извлечь эту экспертизу. Я знаю, как структурировать ответы так, чтобы они превратились в ТЗ. Я знаю, как не пропустить детали, которые вы считаете «очевидными» — но без которых разработчики не смогут работать.
Мы играем в дополнение, а не в замену.
Звучит странно, но это правда.
Если бы я был «специалистом по металлообработке», я бы думал в терминах металлообработки. Я бы предполагал, что вы работаете «как все». А вы работаете не «как все». У вас есть свои нюансы, свои исключения, свои «у нас так принято».
Именно эти нюансы и исключения чаще всего ломают системы. Потому что «стандартное» решение не учитывает «нестандартные» процессы.
Я не знаю ваш бизнес — поэтому я не делаю предположений. Я задаю вопросы. И записываю ответы. Без домыслов.
Процесс не линейный. Я не иду по пунктам «от начала до конца». Я двигаюсь от обобщения к частному.
Сначала я рисую общую картину — что происходит. Потом начинаю «расщеплять» её на детали.
Я не знаю, что именно продаётся. Но я знаю логику B2B-заказов:
Вопрос с моей стороны фактически сводится к одному: «Есть ли у вас в 1С справочник товаров с актуальными остатками? В каком состоянии этот справочник? И есть ли API, через которое мы можем получить эти данные?»
Всё. Мне не нужно знать, что это за мясо. Мне нужно знать, как система должна получить данные о нём.
Этот вопрос я адресую вашему специалисту по 1С. Или бухгалтеру. Или тому, кто отвечает за учёт. Я не спрашиваю «как устроен ваш бизнес» в общем. Я спрашиваю конкретное:
«Что есть? Где лежит? Как к этому обратиться?»
Я не изучаю ваш бизнес. Я изучаю ваши данные:
И я изучаю ваши потребности:
Я не спрашиваю «как вы работаете» в общем виде. Я спрашиваю «что должно произойти в системе, когда происходит Х».
Ваша задача — зарабатывать деньги. Моя задача — не мешать вам это делать.
Я не дёргаю вас созвонами по три раза в день. Я не задаю вопросы, на которые можно ответить в переписке. Я не превращаю проектирование в бесконечные совещания.
Если мне нужен контакт специалиста — я прошу его.
Не для того, чтобы обсудить рыбалку или анекдоты. А для того, чтобы задать конкретный технический вопрос и получить на него ответ.
Это единственно правильное распределение ролей:
Бизнес занимается бизнесом.
Технари занимаются техническими вопросами на своём уровне.
Я — связующее звено между ними.
Я ценю время — и ваше, и своё.
Я не пытаюсь «понять ваш бизнес» в общем виде.
Я не хожу по производству, не смотрю на станки и не обсуждаю поставщиков. Всё это — не моя зона. Моя зона — это движение данных между системами.
Я не учу вас управлять бизнесом. Я помогаю вам описать его так, чтобы разработчики поняли, что нужно сделать.
| Страх | Реальность |
|---|---|
| «Вы не знаете наш бизнес» | Я не должен его знать. Я должен уметь его описать. |
| «Это сложно объяснить» | Это сложно только если не задавать правильных вопросов. |
| «Мы работаем не как все» | Именно поэтому я не делаю предположений. |
| «Как вы поймёте наши процессы?» | По шагам. От обобщения к частному. От данных к потребностям. |
| «Меня будут дёргать созвонами» | Нет. Я общаюсь с техническими специалистами, а бизнес занимается бизнесом. |
Я задам вопросы. Я помогу сформулировать.
Бесплатный экспресс-аудит — до начала работы.