[Devel] [Talk] "Заказчики" и " Исполнители"

[Evgeny Sinelnikov]

Здравствуйте,

я решил продолжить обсуждение в этой ветке (2yv@: проверь свой
почтовый клиент на предмет кодировок)

 г. 16:03 пользователь Иван Дончевский <yv на etersoft.ru> написал:
> Я за третий вариант. Когда покупатель приходит и говорит, что ему нужно.
> У нас же опытный покупатель, не первый раз уже совершает покупку.
> Я сам сейчас всегда, когда хожу в магазин, заранее знаю, что мне нужно,  хотя
> бы по основным аспектам.
>

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

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

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

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


> А продавец уже предлагает "модели разных фирм и дизайна", предлагает некоторые
> дополнительные вещи, которые подходят ко всему остальному, выражаясь этим
> языком. Или говорит в крайнем случае - этого товара нет, я вам могу
> предложить что-то похожее.
>

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

> Тут явный намек, что сейчас второй вариант... Поэтому я предлагаю попробовать
> в следующий раз прийти к третьему, а если ну сооовсем никак, то будем
> пытаться реализовать хотя бы первый. И будем тогда отводить отдельное время
> исключительно на согласование.

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

Чем более чётко сформулирует требования заказчик, тем меньше он
получит, если исполнитель не захочет идти ему навстречу. Поэтому,
обычно, так называемое "техническое задание" составляет не заказчик, а
исполнитель. При этом, заказчик его утверждает. ТЗ, в этом случае,
присутствует как артефакт - документ, в котором отражены все основные
моменты.

Таким документом, конечно, можно считать набор багов в багзиле, но
отразить в таком документе всё, что нужно, довольно затруднительно.
Такие документы мы храним, как минимум, на wiki.

Можно ли сказать, что сейчас у нас есть такой документ для каждого из
ведущихся проектов?
Судя по тому, что я наблюдаю на wiki - нет.

А всё потому, что кроме консультанта в магазине есть ещё менеджер,
который задал консультанту набор ограничений о том, какую мебель, и в
каком виде и за какую стоимость способны собрать поставщики.
Консультант придумать эту информацию не может. А если и может, то не
должен.

У нас же покупка ведётся непосредственно у поставщиков, минуя магазин
и консультантов. Без посредников - всегда выгоднее. Но никто не
говорил, что проще. Весьма непросто исполнителю играть роль
консультанта, тестера, разработчика, проектировщика и менеджера.

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

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

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

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

У заказчика должно быть три варианта ответа на пожелание:
- да, нас это есть;
- нет, мы этим не занимаемся;
- дайте нам время, мы подумаем, оставьте контакты, мы с вами свяжемся
в любом случае в течении фиксированного срока.

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

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

Разделение этих ролей не случайно. Найти человека способного, и, что
более важно, желающего, играть все эти роли сразу, очень не просто.
Потеря такого человека означает потерю, как минимум, времени, или даже
всего проекта. Заменить же человека играющего одну из ролей, намного
проще, чем человека, играющего несколько ролей.


-- 
Sin (Sinelnikov Evgeny)