Принципы профессионализма через истории. Про слепоту и вопросы

Управление - Личная эффективность

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

- Это что же получается, мы 2 недели работали зря?

- Похоже, да.

Чувствовать себя дураком неприятно. Хочется поругать себя или поискать виноватых. Хочется просто уйти от всего этого подальше.

Много лет назад я взялся за задачу: написать конфигурацию с нуля на управляемых формах. Я был рад, УФ только появились, и эта работа могла дать хороший опыт. Тем более, я всегда хотел написать что-то с нуля, в этом есть какая-то романтика.

Но я не учел одного – это оказалось никому не нужно.

Заказчик написал красивое ТЗ. В нем было прописано, что нужно сделать, вплоть до объектов системы. Вроде бы все ясно.  

Сейчас я понимаю, что закрыл глаза на многие вопросы. Мне очень хотелось быстрее начать. Казалось, что в настолько подробном ТЗ не может быть неясностей. А заказчик с таким уверенным голосом точно знает, чего хочет.

Те же вопросы, которые почти прорывались через желание их не видеть, казались слишком очевидными. И, чтобы не показаться идиотом, я их не задал.

Фактически, я «продал» себе идею, что все будет хорошо. Но в итоге все было не так. Первая ласточка прилетела в голову через 4 дня:

- Подскажите, я сделал пункт 5, но не могу понять один момент. Если все делать как написано, документ в конце не будет проводиться, так как остатков не хватает. Так и планировалось?

- Хм. Нет. Видимо, там надо что-то еще добавить. Вы знаете, ТЗ писал не я. Вы не могли бы подсказать, как будет правильно?

- Пока не знаю. А кто писал ТЗ?

- Он уже у нас не работает и связи с ним нет.

Вот так через 4 дня работы я понял, что задание с пробелами и спросить не у кого. И чем больше я уточнял, тем больше было непонятного. Куда я смотрел раньше?

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

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

- А вам эта конфигурация вообще зачем?

- Ну, чтобы вручную не вносить данные в УПП.

- Но вы и так их будете вносить вручную. Просто в другую систему. Может, должен был быть какой-то выигрыш времени?

- Да, должен был быть. Но после всех уточнений я его не вижу.

- Я тоже. Может быть, планировалась какая-то другая польза? Например, работа через web?

- Нет. Этого не надо.

Наступило молчание.

- Это что же получается, мы 2 недели работали зря?

- Похоже, да.

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

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

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

По итогам я вывел принципы:

  1. Уточняй цели. Без понимания цели сложнее увидеть скрытые проблемы. А иногда оказывается, что задачу надо делать по другому или вообще не надо делать.
  2. Анализируй задачу досконально. Если хочется пропустить какой-то момент - не позволяй себе это. Представь, что у тебя задача найти изъян, найти «мутную» формулировку, понять, что может пойти не так. И ищи.
  3. Задавай вопросы пока не поймешь все до конца, даже если ответ вроде и так понятен. Если есть хоть небольшая вероятность понять неправильно, надо уточнить. А чтобы заказчик не начал возмущаться очевидным вопросам, говори, что просто хочешь удостовериться, что все понял правильно. И рассказывай ему, как понял. Тогда он будет понимать, что ты уже усиленно подумал прежде чем спросить. А значит вопрос нужный.

Автор статьи: Андрей Макаров, компания Neti

Первая история доступна по ссылке Принципы профессионализма через истории. История первая

Кому интересно подробнее узнать про развитие нетехнических навыков у разработчиков, можно голосовать за мой доклад на Infostart Event «Нетехнические навыки для разработчиков. Зачем они нужны? Как развивать?» 

См. также

Комментарии
1. p m (pm74) 36 17.08.17 18:19 Сейчас в теме
нормальная статья, еще бы от себя добавил , что иногда при обсуждении с заказчиком все вопросы и цели вроде бы проговариваются, но в итоге получается что разработчиком и заказчиком подразумевались совершенно разные вещи. Вопрос формулировок так сказать.
IvanovAV; sergelemon; Aleskey_K; Yakud3a; Neti; +5 Ответить
2. Александр Синиченко (nytlenc) 87 17.08.17 18:30 Сейчас в теме
А еще иногда (процентов 90 случаев) у заказчика семь пятниц на неделе. Сегодня хочу одно, завтра другое, после завтра третье. В итоге вообще не то давайте все переделаем. И благодарностью будет конечно - ваша тупая программа не работает как надо!
alsegor; Nelli_A86; IvanovAV; sergelemon; Aleskey_K; rusmil; olbu; Solovyeff; Neti; +9 1 Ответить 1
3. Николай Больсунов (boln) 937 17.08.17 19:36 Сейчас в теме
Заказчик написал красивое ТЗ. В нем было прописано, что нужно сделать, вплоть до объектов системы.
Это не его заказчиковское дело, какие объекты будут в системе. Заказчик "заказывает" вход и выход, остальное - вопрос реализации.
IvanovAV; Aleskey_K; Natalia; maxopik2; Starec_I; +5 Ответить 2
4. Олег Николаев (o.nikolaev) 195 18.08.17 07:33 Сейчас в теме
(3) При все уважении, Николай. И этого не могут - "вход и выход" заказать. Мычат только.
А история просто замечательная! Порадовало попадание:
А заказчик с таким уверенным голосом точно знает, чего хочет.
5. Иван Белокаменцев (1c-intelligence) 1317 18.08.17 08:01 Сейчас в теме
Уточняй цели. Без понимания цели сложнее увидеть скрытые проблемы. А иногда оказывается, что задачу надо делать по другому или вообще не надо делать.

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

Анализируй задачу досконально.

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

Задавай вопросы пока не поймешь все до конца

Формулировка как в цикле Пока Цикл, но вроде можно не ограничивать условие выхода из цикла. Выходом может быть достигнутая совсем другими методами цель (не теми, что в задаче). У всех, наверное, бывала ситуация, когда создаешь готовое решение за время, в течение которого заказчик от тебя ждет прочтения ТЗ и вопросов.
IvanovAV; JohnyDeath; MishaHD; Neti; +4 Ответить 1
6. Андрей Суханцов (&rew) 6 18.08.17 08:19 Сейчас в теме
Ничто так не укрепляет веру в успех проекта как предоплата! Вы когда брались за проект, Вас спросили "Как Вы видите?". Если нет, то Ваше дело выполнить проект и получить деньги. Даже если это не нужно, все будут знать, что Вы - профессионал и с Вами можно работать. Если Вас не спросили, а вы начинаете задавать "лишние" вопросы, т.е. вопросы не типа "КАК" а типа "ЗАЧЕМ", то это очень часто выглядит как попытка "отъехать" от проекта и, как следствие, невозможность выполнить именно Вами поставленную задачу (в глазах Заказчика).
k_rostik; IvanovAV; temdj; +3 Ответить 1
7. Николай Больсунов (boln) 937 18.08.17 09:42 Сейчас в теме
(4)
При все уважении, Николай. И этого не могут - "вход и выход" заказать. Мычат только.
Вы, Олег, еще более безжалостны, чем я :)

Да, это серьезная задача - научить заказчика говорить членораздельно. Мне приходилось интервьюировать заказчика с целью написать однозначно трактуемое обеими сторонами ТЗ. Прямо ощущал себя в роли следователя, который "колет" матерого преступника...

И ведь нигде не учат этому искусству. Или, может, уже учат?
temdj; PAVI; +2 Ответить
8. Александр Федотов (6JIoHguH) 24 18.08.17 11:02 Сейчас в теме
(6)
Если нет, то Ваше дело выполнить проект и получить деньги. Даже если это не нужно


Если честно, то мне кажется, что разработчик больше поднимется в глазах заказчика, когда будет демонстрировать, что он заинтересован в решении задачи (пусть даже больше заказчика), чем просто бездумно ее выполнит, пусть даже она и не нужна.
Гораздо приятнее получить отзыв от заказчика типа:
- Пришел разработчик и не ринулся бездумно выполнять задачу а все проанализировал и предложил более рациональное решение (переубедил меня, что мне это не нужно), в результате я сэкономил. Пожалуй, я обращусь к вам еще раз.
чем:
- Сделал нам этот разработчик какую-то ерунду, теперь не знаем, что с ней делать. И зачем только обратились к вам. Зря деньги потратили.

Хотя, просто, может мне еще не попался *тот самый заказчик* :)

И это не будет выглядеть как "попытка отъехать от проекта", если грамотно объяснить все заказчику. Никто не любит просто так тратить деньги, поэтому, я думаю, что при грамотном обсуждении задачи (и с рационально мыслящем заказчиком) все будет хорошо :)
IvanovAV; Neti; Starec_I; +3 Ответить 1
9. Андрей Суханцов (&rew) 6 18.08.17 11:30 Сейчас в теме
(8) "- Пришел разработчик и не ринулся бездумно выполнять задачу а все проанализировал и предложил более рациональное решение (переубедил меня, что мне это не нужно), в результате я сэкономил. Пожалуй, я обращусь к вам еще раз. "
А в жизни это выглядит так.
- Пришел мальчик, начал нам говорить, что нам это не надо, что понимает больше нас в наших бизнес-процессах. Чудак какой-то, ему деньги не нужны что ли?
и
"- Сделал нам этот разработчик какую-то ерунду, теперь не знаем, что с ней делать. И зачем только обратились к вам. Зря деньги потратили. "
- Сделал нам разработчик то, что мы просили. Оно работает именно так, как мы хотели. Хоть сейчас это уже не актуально, но человек свою работу сделал качественно. В следующий раз обратимся к нему же.

"...Никто не любит просто так тратить деньги..."
Вот это в точку. И люди это понимают очень хорошо. И они не поймут, почему вы тратите свое время/деньги и не хотите заработать.
10. Ivan Starec (Starec_I) 18.08.17 13:29 Сейчас в теме
(9)
Сделал нам разработчик то, что мы просили.
- это уже фантастика.
sergelemon; temdj; zqzq; 6JIoHguH; spiderlexx; +5 Ответить
11. Александр Федотов (6JIoHguH) 24 18.08.17 13:47 Сейчас в теме
(9)
начал нам говорить, что нам это не надо

А вот тут уже нужно четко понимать, какой перед тобой заказчик. Если заказчик считает себя самым крутым, то бессмысленно его в этом переубеждать (может, у Андрея и на эту тему есть история? :) ) и лучше сделать так, как он просит.
Если заказчик адекватный, грамотно воспринимает критику и осознает, что основной целью разработчика является не просто сделать, что его просят, а еще и сделать заказчика счастливым, то до него можно донести мысль, что его деньги будут потрачены в пустую.
P.S.
Опять же оговорюсь, мне еще не попался *тот самый заказчик* :)
12. Andrey Erastov (tailer2) 18.08.17 13:57 Сейчас в теме
не смешно
вопрос был всего один:кто это написал
13. Алексей А. (Разумов) 18.08.17 14:07 Сейчас в теме
Из выводов пункт №3 считаю самым важным.
14. Андрей Суханцов (&rew) 6 18.08.17 14:31 Сейчас в теме
(11) Александр, историй полно:)
"Скоро стану я седым и старым,
Вот тогда и напишу свои я мемуары..."
15. Яков Коган (Yashazz) 2119 18.08.17 21:43 Сейчас в теме
Слабаки) Любое ТЗ, если только его не писал профи-методист-внедренец, будет с пробелами, и таких подавляющее большинство. Надо или "чуйку" включать, или опыт (знание подводных камней), или делать универсал. А не ждать от заказчика у моря погоды.

Много раз делал задачу "вслепую". Пару конфигураций с нуля так написал. Работают. И знаете почему? Там, где у меня была неясность, я делал общее настраиваемое решение, универсальный регулируемый блок, как угодно, но чтоб потом можно было быстро докрутить, когда появится понимание. Благо общие бизнес-процессы предметных областей и хоз.операции учёта более-менее стандартны. А детали настраивались уже потом "на лету". Универсальность наше всё)

Да, это дольше и дороже по времени. Но это стократ окупается при запуске и опытно-промышленной эксплуатации, когда вдруг оказывается, что "всё не так" и "имели в виду не это". Причём это бывают как универсальные архитектурные решения, так и просто правильно структурированный и параметризованный код.
16. Валерий М (VmvLer) 19.08.17 00:34 Сейчас в теме
банально, скучновато и предсказуемо
в 5-м классе средней школы такие статейки пишут

это исключительно мое впечатление как на духу
17. г. Казань Рустем Гумеров (Rustig) 822 19.08.17 09:21 Сейчас в теме
(2) так говорят, если за работу не платят = не видят ценности работы разработчика (внедренца). с такими надо работать по предоплате (частичной или полной), чтобы почувствовали цену
18. г. Казань Рустем Гумеров (Rustig) 822 19.08.17 09:23 Сейчас в теме
(3) ага, точно = все учатся на своих ошибках
19. г. Казань Рустем Гумеров (Rustig) 822 19.08.17 09:24 Сейчас в теме
(4) сейчас надо одно, в другой момент - другой контекст = надо другое - нормальное требование к программе 1с - начните работать по предоплате - это спускает заказчика с небес на землю
IvanovAV; &rew; PAVI; +3 Ответить
20. Алексей Иванов (IvanovAV) 20 23.08.17 12:34 Сейчас в теме
Вам денег за эти 2 недели заплатили??
Если нет, тогда чем обосновали не уплату? Вины вашей нет!
Если бы сотрудник который в штате и на окладе делал бы этот проект, была бы вероятность что ему не заплатят его честно заработанную зарплату?
Были в похожей ситуации, приехали на переговоры КА 1.1, просят переписать блок себестоимости и весь партионный учет. Начали задавать вопросы, оказалось, то что они хотят решается типовыми средствами через ТипЦен ПлановойСебестоимости и флаг в правах запрещающий продавать выше этого типа цен. Вторая задача, привязать шаблоны проводок к справочнику проекты, мы сказали есть типовой механизм счета учета контрагентов. В результате реализация двух ТЗ, заняла несколько человеко часов, вместо нескольких человеко недель, с туманной перспективой дальнейших обновлений. А мы получили лояльного клиента.
21. Компания Нэти (Neti) 268 23.08.17 16:33 Сейчас в теме
(20) Да, клиент тогда сам поднял вопрос оплаты и заплатил денег без каких-либо обсуждений. Но в итоге клиент был не доволен ситуацией. И скорее всего я у клиента в голове связывался с негативными воспоминаниями, так как какое-то время он с неохотой работал со мной. Поэтому я достаточно долго менял это отношение максимально проактивными и безошибочными действиями с моей стороны.
IvanovAV; +1 Ответить
22. Компания Нэти (Neti) 268 23.08.17 16:43 Сейчас в теме
(16)
Правильно ли я понял, что хотелось бы историю с более интересным сюжетом? Или хочется больше полезных практических идей в ней?
Эти истории я изначально пишу для своих сотрудников, чтобы лучше объяснить наши принципы. Так как принципы без истории не всегда сразу хорошо воспринимаются.
Но если история эмоционально не задела, значит надо другую.
23. Валерий М (VmvLer) 23.08.17 17:08 Сейчас в теме
(22) Я же написал - изложение скучновато.
Когда такое рассказывают обычно клонит ко сну и вылетает из головы сразу после звонка на перемену)

Чтобы принципы запомнили в повествовании желательно ввести хорошие, лучше яркие якоря. Поговорите со штатным психологом и пишете статьи вместе.
24. Компания Нэти (Neti) 268 23.08.17 17:16 Сейчас в теме
(23)
Понял. Спасибо за обратную связь.
25. Компания Нэти (Neti) 268 23.08.17 17:19 Сейчас в теме
(5)
Как всегда полезные дополнения) Спасибо!
Оставьте свое сообщение