Желание неукоснительно придерживаться ТЗ при недостигнутых задачах бизнеса.
Этот тезис больно ударит по вашему самолюбию, если вы привыкли к уровню обслуживания «нет в ТЗ – идите мимо». Тем не менее, если вы хотя бы чуть-чуть поменяете свое мнение в сторону большей клиентоориентированности, то сможете понять, о чем я.
Знаю-знаю, вы – крутой программист и тут же возразите мне – а что же, я должен предвидеть все, что нужно бизнесу? Должен догадаться, чего хочет заказчик? Бесконечно реализовывать его странные хотелки?
А имеете ли вы моральное право задавать такие вопросы? Проверьте, что из этого списка вы сделали для этого:
Провели ли вы предварительный анализ требований из ТЗ, прежде чем приступить к его реализации?
Поставили ли вы под сомнение какие-либо пункты в спецификации или просто
взяли под козырекполучили аванс?Предложили ли вы заказчику альтернативные варианты решения?
Если ваш ответ «ничего», значит вы просто формалист, перекладывающий ответственность с себя на заказчика.
Вы до потертости пальцев будете тыкать в ТЗ, говорить, что оно утверждено и подписано заказчиком. Что он сам виноват в том, что не углядел/не дописал, а теперь топает ногами и требует, чтобы вы доделали работу, но никогда не признаетесь, в том, что не смогли здраво оценить свои силы, потому как некомпетентны.
Знайте, если вы так делаете, то вы низкоквалифицированный программист-техник, не больше!
Нужны обоснования? – пожалуйста.
Что говорит профстандарт о вашей квалификации?
Вы наверняка знаете, что есть так называемые профессиональные стандарты. Они разработаны компетентными органами с целью определить эталонные навыки и умения специалистов, отвечающих за свою работу.
Здесь находится профстандарт для программистов. Это сайт министерства труда.
Если мы заглянем внутрь профстандарта, то обнаружим, что одна из трудовых функций программиста выглядит так:
Написание программного кода с использованием языков программирования, определения и манипулирования данными
В рамках этой трудовой функции определены следующие трудовые действия:
Создание программного кода в соответствии с техническим заданием (готовыми спецификациями)
Оптимизация программного кода с использованием специализированных программных средств
Оценка и согласование сроков выполнения поставленных задач
Действительно, исходя из этого стандарта, мы видим, что программист создает программный код, опираясь на техническое задание (готовую спецификацию). Для этого ему достаточно владеть синтаксисом выбранного языка программирования, уметь оптимизировать программный код и проводить оценку работ по срокам.
Интересно, что программист, который обладает навыками кодинга по ТЗ, получает от Минтруда только 3 пункта к квалификации. Это программист уровня ПТУ, совершенно обоснованно в терминах профстандарта именуемый «Младший программист» или «Техник-программист».
Такой специалист может заявить: «В ТЗ этого нет». Формально он будет прав – это его уровень. При этом ему все равно, реализована ли задача бизнеса, главное, что свою часть работы он сделал.
Аналогом такого подхода могут служить следующие примеры:
Лампочку вкрутил, но свет есть только в 70% теплицы. Для появления завязей необходим уровень наполняемости светом 99%.
Реализовал функцию оплаты заказов, при этом не учел, что оплачивать заказы могут только зарегистрированные пользователи.
Сделал парсер для сайта, но подтягиваемые данные выводятся вкривь-вкось.
Смотрим далее. Есть такая трудовая функция как
Анализ требований к программному обеспечению
А вот это уже посложнее будет, ведь для того, чтобы реализовать столь очевидно-полезную для бизнеса трудовую функцию, действительно нужен фундаментальный подход и мозги, а также пресловутые софт-скилс, которыми не обладают «техники» квалификации 3.
Читаем состав трудовых действий:
Анализ возможностей реализации требований к программному обеспечению
Оценка времени и трудоемкости реализации требований к программному обеспечению
Согласование требований к программному обеспечению с заинтересованными сторонами
Оценка и согласование сроков выполнения поставленных задач
И необходимые умения:
Проводить анализ исполнения требований
Вырабатывать варианты реализации требований
Проводить оценку и обоснование рекомендуемых решений
Осуществлять коммуникации с заинтересованными сторонами
Здесь на первый план выходят социально-ориентированные навыки специалиста: умение общаться, задавать вопросы, вести дискуссию, в чем-то отстаивать свою позицию, где-то прислушаться к иной позиции.
Нетрудно заметить, что из 4 трудовых действий и 4 необходимых умений присутствуют только 2 технических навыка!
А теперь немного о том, как называется эта должность и уровень необходимой квалификации:
Становится очевидным, что для того, чтобы быть в авангарде своей профессии и приносить бизнесу пользу, нужно быть не просто человеком-печатной машинкой кода, а аналитиком.
Вы имеете право говорить о «бесконечных доделках», если вы:
Предварительно и в полной мере убедились, что требования, положенные в ТЗ, определяются бизнес-задачей и неразрывно связаны с ней.
Задали заказчику исчерпывающие вопросы и утвердились в понимании «почему» и «зачем» необходимо реализовать ту или иную бизнес функцию, в результате которой родились функциональные требования, описанные в ТЗ.
Другими словами программист, обладающий развитыми аналитическими навыками, в любой момент времени понимает, как именно конкретное функциональное требование соотносится с бизнес-задачей и наоборот – какой бизнес-задачей порождено соответствующее функциональное требование, на что оно опирается.
И называется такой программист ведущим!
Для него подход «такого не было в ТЗ» – катастрофа, ведь он осознает, что ТЗ – это сфера его ответственности. Ведущий программист выполняет 60% работы на этапе аналитики и только 40% отводит на работу с кодом. Он не делает ТЗ притчей во языцех, доказывая несостоятельность заказчика. Скорее, наоборот, он чувствует себя несостоятельным, если, сделав работу по ТЗ, заказчик получает не тот результат, на который рассчитывал.
Это колоссальная разница в подходах и мышлении – заметьте!
Если программист не видит связи задач с бизнесом и не принимает каких-либо действий для обнаружения такой связи, то это программист-техник.
Как перестать быть программистом-техником и выйти на уровень компетенций ведущего программиста?
Чтобы соответствовать высоким показателям Минтруда и ожиданиям заказчиков нужно, в первую очередь, переориентировать фокус своего внимания с технической части на бизнес. Хороший аналитик – это всегда про взаимопонимание людей. Нужно учиться общаться, задавать вопросы, интересоваться той сферой деятельности, потребности которой вы решаете. Аналитик должен знать и предметную область проекта, и применяемые техники разработки.
Вот примерный спектр умений для прокачки в себе аналитика и успешного бизнес-коммуникатора:
Анкетирование. Умение сделать качественную анкету под проект можно считать базовым навыком перед тем, как вступать в очные интервью.
Навык индивидуального интервьюирования. Сюда можно отнести персональные встречи, интервью по телефону и навыки выявления требований посредством переписки.
Групповые интервью. На групповых интервью присутствует несколько заинтересованных лиц. Ничего сложного. Просто здесь лучше проявляются ваши навыки самопрезентации, умение владеть вниманием собеседника, задавать вопросы и удерживать формат беседы, необходимый для получения результата.
Наблюдение. Иногда, для того, чтобы понять, как что-то работает, достаточно просто понаблюдать за этим. Уверяю, что посидев полтора часа в живом отделе продаж и просто наблюдая за менеджерами, вы точно поймете, как адаптировать эту злосчастную CRM так, чтобы руководство осталось довольным.
Прототипирование и создание бизнес-схем с последующим их обсуждением. Прототипы великолепны в качестве первого приближения результата. Если вы пришли на встречу с клиентом или общаетесь с ним в формате конференции онлайн – разверните флип-чарт и порисуйте. Ваша дискуссия обретет иной качественный характер и понимание.
Кроме того, рекомендую почитать следующую литературу:
Карл Вигерс, Джой Битти – Разработка требований к программному обеспечению. Практические приемы сбора требований при разработке программных продуктов.
Дин Леффингуэлл, Дон Уидриг – Принципы работы с требованиями к программному обеспечению. Унифицированный подход.
Этот перечень неограничен, но вполне достаточен на начальном этапе, чтобы открыть себе путь к более интересным проектам. Это ваш иной уровень зрелости как специалиста с доступом к другому уровню вознаграждения.
Удачи вам и крутых проектов!
