Принципы профессионализма через истории. Про слепоту и вопросы
Мы продолжаем выкладывать истории, объясняющие наши принципы. Принципы, которые помогают эффективнее взаимодействовать. И с клиентами, и с коллегами. В этой истории я бы хотел рассказать про умение вовремя задавать правильные вопросы. И про то, как это у меня не получилось.
- Описание
- Подробнее
Описание
— Это что же получается, мы 2 недели работали зря?
— Похоже, да.
Чувствовать себя дураком неприятно. Хочется поругать себя или поискать виноватых. Хочется просто уйти от всего этого подальше.
Много лет назад я взялся за задачу: написать конфигурацию с нуля на управляемых формах. Я был рад, УФ только появились, и эта работа могла дать хороший опыт. Тем более, я всегда хотел написать что-то с нуля, в этом есть какая-то романтика.
Но я не учел одного – это оказалось никому не нужно.
Заказчик написал красивое ТЗ. В нем было прописано, что нужно сделать, вплоть до объектов системы. Вроде бы все ясно.
Сейчас я понимаю, что закрыл глаза на многие вопросы. Мне очень хотелось быстрее начать. Казалось, что в настолько подробном ТЗ не может быть неясностей. А заказчик с таким уверенным голосом точно знает, чего хочет.
Те же вопросы, которые почти прорывались через желание их не видеть, казались слишком очевидными. И, чтобы не показаться идиотом, я их не задал.
Фактически, я «продал» себе идею, что все будет хорошо. Но в итоге все было не так. Первая ласточка прилетела в голову через 4 дня:
— Подскажите, я сделал пункт 5, но не могу понять один момент. Если все делать как написано, документ в конце не будет проводиться, так как остатков не хватает. Так и планировалось?
— Хм. Нет. Видимо, там надо что-то еще добавить. Вы знаете, ТЗ писал не я. Вы не могли бы подсказать, как будет правильно?
— Пока не знаю. А кто писал ТЗ?
— Он уже у нас не работает и связи с ним нет.
Вот так через 4 дня работы я понял, что задание с пробелами и спросить не у кого. И чем больше я уточнял, тем больше было непонятного. Куда я смотрел раньше?
Иногда, если нам чего-то очень хочется, мы не неосознанно закрываем глаза на любые изъяны. Хочется просто двигаться вперед. В эти моменты сложно сказать себе «стоп» и взглянуть на ситуацию критически. Нужна сила воли, дисциплина. Нужно понимание, что сейчас вы во власти эмоций и это мешает быть объективным.
В течении следующей недели я перечитал все ТЗ, перепроверил все утверждения, уточнил у нескольких людей все, что только смог. Мы с заказчиком расширили ТЗ пунктами, без которых ничего бы не работало. И, наконец, я задал заказчику главный вопрос:
— А вам эта конфигурация вообще зачем?
— Ну, чтобы вручную не вносить данные в УПП.
— Но вы и так их будете вносить вручную. Просто в другую систему. Может, должен был быть какой-то выигрыш времени?
— Да, должен был быть. Но после всех уточнений я его не вижу.
— Я тоже. Может быть, планировалась какая-то другая польза? Например, работа через web?
— Нет. Этого не надо.
Наступило молчание.
— Это что же получается, мы 2 недели работали зря?
— Похоже, да.
Мы должны понимать, что желание закрыть глаза на возможные проблемы — это беда всех. Причины могут быть разные. В данному случае человек, писавший ТЗ, просто хотел побыстрее решить свою задачу и уволиться. И он так же неосознанно, как и я, не задавал сам себе вопросы о том, что может пойти не так.
Если бы я сразу начал досконально анализировать задачу от понимания цели до понимания деталей работы механизмов, я бы увидел проблемы раньше. И ни я, ни заказчик не потеряли бы 2 недели. Никому не хочется делать что-то не нужное. Вроде даже есть такая пытка, где людей заставляют делать никому ненужные вещи. И никому не хочется терять деньги.
В той истории мы так и не нашли причин дальнейшего создания отдельной конфигурации, фактически повторяющей функционал уже существующей системы. И заказчик отказался от этой идеи.
По итогам я вывел принципы:
- Уточняй цели. Без понимания цели сложнее увидеть скрытые проблемы. А иногда оказывается, что задачу надо делать по другому или вообще не надо делать.
- Анализируй задачу досконально. Если хочется пропустить какой-то момент — не позволяй себе это. Представь, что у тебя задача найти изъян, найти «мутную» формулировку, понять, что может пойти не так. И ищи.
- Задавай вопросы пока не поймешь все до конца, даже если ответ вроде и так понятен. Если есть хоть небольшая вероятность понять неправильно, надо уточнить. А чтобы заказчик не начал возмущаться очевидным вопросам, говори, что просто хочешь удостовериться, что все понял правильно. И рассказывай ему, как понял. Тогда он будет понимать, что ты уже усиленно подумал прежде чем спросить. А значит вопрос нужный.
Автор статьи: Андрей Макаров, компания Neti
Первая история доступна по ссылке Принципы профессионализма через истории. История первая
Кому интересно подробнее узнать про развитие нетехнических навыков у разработчиков, можно голосовать за мой доклад на Infostart Event «Нетехнические навыки для разработчиков. Зачем они нужны? Как развивать?»
