- Фу! До чего же дичь пошла бестолковая — я полдня за ней бегал, чтобы сфотографировать!
- Это ещё мало, теперь ты ещё за ним полдня бегать будешь.
- Это почему же?
- А чтоб фотографию отдать.Каникулы в Простоквашино
Все нижесказанное я писал относительно сферы внутренней разработки и поддержки.
Когда задач много, а ресурса ИТ на всех не хватает.
Я несколько раз наступил на эти грабли сам. Слышал много историй от коллег.
Близкими проблемами являются "Никому не нужный подвиг" и "Супер-аналитик оптимизатор".
Теперь суть:
Разработка выполняется только тогда, когда есть заказчик, а у заказчика выявлена четкая потребность.
Любая строчка кода пишется только тогда, когда заказчик готов тратить время и силы на:
- постановку: беседу с аналитиками для составления ТЗ;
- внедрение: работу с сопротивлением, повышенную нагрузку при имплементации.
Только тогда, когда выполнены указанные выше условия, можно тратить время программистов на разработку, а аналитиков на составление ТЗ.
В противном случае у вас есть огромный шанс уподобиться Шарику и бегать за дичью пользователями и при составлении ТЗ и, самое неприятное, при внедрении.
Ниже реальные кейсы с граблями (и не только моими). Все имена изменены, все совпадения случайны.
1. Нахожу на своем месте расстроенного разработчика.
Суть: Он решил облегчить жизнь пользователям. Сделал автоматическое заполнение некоторых полей, зависимые списки и пр. Потратил время свое. А когда пришел "сдаваться" оказалось, что это никому не нужно - порядок заполнения полей не такой как на форме (слева - направо, сверху-вниз), а свой. И зависимость не срабатывает, а только мешает.
Это больше случай "Никому не нужного подвига".
Вывод: нет заказчика - нет разработки.
2. Нахожу в трекинговой системе таску, которая сделана, но не принимается и не тестируется заказчиком уже больше месяца. Разработчик уже и не помнит детали ТЗ. И исправление каких-то замечаний для него - это колоссальная потеря времени на то, чтобы "вкинуться" по этой давно забытой задаче.
Суть: ТЗ ставил не заказчик, а как раз внутренний аналитик (о таком вот здесь написано). Т.е. заказчику это не нужно. Он просто, чтоб от него отстали, назвал некую проблему (или согласился с предположением аналитика, что это проблема) и занимался дальше своими делами. У функционала дел хватает. А аналитик решил, что вот, это его находка, его шанс "сделать мир лучше". Он и расстарался: в ТЗ и плюшки и бантики, и кнопочки розовые и проверки всевозможные.
Вывод: постановщик ТЗ - не заказчик. Внутренний аналитик часто просто посредник и у него иные цели. Хотя исключения возможны и об этом важно помнить.
3. Руководитель подразделения выходит на разработчиков с просьбой выделить аналитика под "большую автоматизацию". Описывает крупными мазками суть проблемы: старая программа для связи с госорганами, которая часто виснет, не обменивается данными с основной ERP системой. Нужно или найти новую или создать что-то подобное самим как один из модулей в ERP системе (по описанию там программа - просто небольшая база данных и воссоздать ее будет не так уж и сложно). Все логично. Нужно поработать. Проект в таком общем виде акцептуется на всех этапах вертикали принятия решений. Через день расстроенный аналитик приходит ко мне и просит снять с него проект.
Выясняю: Руководитель со своими сотрудниками "страдающими" от неавтоматизированной работы не поговорил. И пришедший к ним улучшать их участь аналитик дооолго от них выслушивал, что у них и так все хорошо, что их программа быстрая, что она удобная потому, что у нее есть связь с БД этого самого госоргана. И никакими данными с ERP никто не обменивается.
Вывод: Царь-то не настоящий. У заказчика на самом деле нет проблемы, но есть желать не оставаться в стороне и поучаствовать в процессе автоматизации предприятия - быть в тренде, так сказать.
В реальности такой кейс, когда руководитель настолько не знает суть работы подчиненных, в чистом виде встретить сложно. Но нужно понимать, что такое бывает. Может и не настолько "отморожено", как показано выше, но от этого не легче по финалу.
Общий вывод: выясняйте реального заказчика, выявляете его реальные проблемы и заинтересованность.
Замечание.
Иногда потребность в автоматизации есть не на уровне функционалов, которых все устраивает, а на уровне первого лица. Это ничего не меняет - нужно все равно найти тех, кому это нужно и взаимодействовать с ними.
! И, очень важно, у вас должна быть возможность поддерживать то, что вы создали.
Не бывает написанного кода, который не нужно поддерживать.
Есть пользователи, а значит есть вопросы, есть изменение процессов, значит есть доработки системы.
Исключения лишь подтверждают правила (классная фраза, правда?).
Поэтому:
1. Нужен реальный заказчик.
2. Нужно иметь возможность потом сопровождать созданное (об этом более развернуто здесь).
