Все чаще сталкиваюсь с ситуацией, когда на проект выделяется специальный человек с гордым названием "Аналитик", который является, по существу, всего-лишь записывателем слов, которые он услышал от заказчика. При этом задача часто даже не подвергается критическому анализу. Как услышал, так и перенес в таск-трекер. Более того, разработчики требуют, чтобы их оградили от заказчика, разжевали задачу и положили в рот, только тогда они радостно снимают с себя ответственность и делают "задачу по ТЗ". Когда на выходе получается самокат вместо вертолета, они говорят, что "так было в аналитике". Самое интересное, что в среднем по отрасли такое положение дел даже считается приемлемым.
Критическое мышление. Это задавание вопроса "зачем" на всех этапах реализации задачи, всеми участниками процесса. В идеале - начиная с заказчика, но помогать ему формулировать требования - это обязанность, должностная обязанность аналитика. Аналитик - это не технический писатель, не оформитель ТЗ. Это человек, который должен взять всю подноготную бизнес-процесса, выявить его цели, влияние на финансовый результат, коммуникации со смежными системами. Разумеется, это сложно. Нужно обладать компетенциями и в сфере бизнеса и в сфере технологий. Такие люди совершенно справедливо ценят себя высоко и хотят больше, чем "описатели задач". Поэтому, на средне-статистический проект их попадает немного.
Что до разработчиков, то удивительно, но факт - они готовы ломать копья насчет оптимальности алгоритмов, потребления памяти и соблюдения SOLID, но совершенно не задаются вопросом: "зачем поставлена задача". Порядка 80% наблюдаемых мной программистов берут задачу, задают несколько наводящих вопросов и делают ее по принципу "как понял, так и сделал". Потом задача спихивается тестировщикам. В самом конце, набор из плохо-понятых задач объединяется в "тестовый контур" и начинается пилотный запуск. Модули не стыкуются, АПИ не согласуются, а главное - программа делает не то, что от нее требовалось в самом начале. И это самое трудное. Код уже написан, все, что можно сделать - это притвориться, что именно это поведение и было заказано. Да, помогают практики непрерывной интеграции и Agile, просчеты и провалы выявляются намного раньше, но корень проблемы - нежелание в самом начале досконально выявить цели, связи и зависимости проекта - никуда не девается. Кто-то может здесь вспомнить мантру постановки задач в стиле "Given-When-Then", SpecFlow и прочий Cucumber, но много ли вы видели проектов, где такие спецификации команда хочет писать без халтуры, по-честному?
Казалось бы, программист - непосредственный исполнитель задания, тот, кто создает плоть и вдыхает жизнь в эфемерную идею, тот кто превращает ее в реальную ценность - он ведь лучше кого бы то ни было может выяснить, как именно ему нужно потратить свои силы на создание этой ценности. Но нет. По невыясненным причинам, программисты как огня боятся "общения с бизнесом". На собеседованиях разработчиков я не раз слышал, как "ограждение от заказчика" преподносится кандидату, как очевидный плюс рабочего процесса. Т.е. очевиден спрос разработчиков на эту опцию. Качество реализации конечного продукта идет более низким приоритетом. Любопытно, отчего так?
Каждую задачу нужно начинать делать с вопроса "зачем". Зачем она поставлена, как она ложится в общую канву проекта? Стыкуется ли она с общими процессами компании, а если нет - почему она имеет право на существование? Человек, который способен задать эти вопросы - сделает проект. На него можно положиться, ему не жалко заплатить за результат. Человек, который таких вопросов не задает в принципе - он кто угодно, но только не аналитик, он секретарь-машинист. Кто угодно, но только не разработчик. Он monkey-кодер.
Посмотреть на задачу с критической стороны, подвергнуть желание заказчика сомнениям - на это ведь не требуется таланта. Почему же это такая редкость в наши дни?
Чаще всего хорошие аналитики вырастают именно из программистов. Способность видеть системные связи и абстракции помогает не только среди операторов кода. Оно помогает и в понимании мира вообще. Как известно, добавление человека в проект только замедлит его окончание. Поэтому, я с радостью возьму на проект программиста с критическим мышлением на двойной оклад, чем программиста и аналитика, которые сожгут время на совместные коммуникации и переписки.
А у вас на проекте есть аналитики?