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