Фрай думает

6 вопросов, которые стоит задать до

Не так важно, до чего стоит задавать эти вопросы: до того, как начать выполнять таск (если ты программист), до того, как прописывать бизнес-модель (если ты стартапер), до того как готовить ужин… Имеет смысл знать ответы до начала какой-либо деятельности.

Кто?

Кто будет делать эту часть? Кто будет пользоваться моим продуктом? Кто будет выступать на конференции? Иногда даже достаточно спросить предлагающего «а кто?» — и он расскажет вам ту часть своего предложения, которая относится к людям.

Что?

Что мы будем делать? Что продаёт этот стартап? Что подают в этом ресторане? Важно понимать не только, какие субъекты (активные участники) рассматриваются в рамках деятельности, но и объекты, коими будут манипулировать.

Где?

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

Когда?

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

Почему?

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

Зачем?

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

6 вопросов, которые стоит задать до: 5 комментариев

  1. Здравия желаю Георгий!
    Увидев твит, сайт — решил, что пожалуй надо зафиксировать свое посещение. Однако почему программиста должны мучить вопросы менеджмента?
    Получил ТЗ, вооружился инструментом, сотворил заказ, расписался в ведомости…
    А таким образом можно опустится и до вопроса о «крыше».

    1. Доброго дня, Валерий Павлович!
      Тут вопрос в целях. Если наша цель «работать, получать деньги» — можно кодить хоть месяцами продукты, которые никому не нужны — лишь бы платили. Если же хочется делать что-то полезное, нужное — надо задумываться не только о том как закодить, но и о других аспектах продукта.
      Второй подход мне ближе. Я разочаровываюсь в себе, когда мой труд никому не нужен. С другой стороны — получаю удовольствие, когда вижу результат.
      Менеджмент, психология, программирование — лишь средство достижения этого результата, оптимизации процесса.

  2. >задумываться не только о том как закодить…
    Да на здоровье! Однако, ежели в проекте бульдозера не предусмотрена кофеварка, то никто в трезвом уме, ее туда не будет вписывать.
    ИМХО, все эти вопросы возникают лишь тогда, когда нет четкой постановки задачи, конкретики. По сути, задача программиста, разработка оптимального кода в четком соответствии с ТЗ, да и всех прочих, причастных к проекту. Но, частенько, клиент не способен грамотно описать свои желания, менеджер боясь упустить выгоду соглашается на все… Прорвемся!

    1. Про кофеварку как раз здравый пример. Если мне предлагают её добавить в бульдозер — я спрошу «зачем»? Далее я буду ожидать каких-то данных, мол бульдозеристы очень просят; или объяснения: мы хотим провести тестирование — есть предположение, что это востребовано, потому что *результаты исследований*.

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

      В общем, ТЗ для меня нынче — точка зрения. Думается, что такой подход более производительный, но требуется вовлечённость разработчика. Не исключаю, что со временем моя точка зрения изменится, а с ней и субъективное представление об истине :)

      1. Представьте два бульдозера — в одном есть кофеварка, а в другом нет. Какой вы купите ?

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>