Кто, чёрт возьми, писал это техзадание?
2026-02-21 13:42 Diff
https://skillbox.ru/media/code/kto-chyert-vozmi-pisal-eto-tekhzadanie/

#статьи

  • 1 апр 2022
  • 0

Кто, чёрт возьми, писал это техзадание?

Если вы не раз проклинали непонятные техтребования — прочитайте этот гайд от разработчика из The New York Times Джастина Фуллера.

Кадр: сериал «Кремниевая долина»

Онлайн-журнал для тех, кто влюблён в код и информационные технологии. Пишем для айтишников и об айтишниках.

Муж, отец, разработчик ПО в The New York Times.

Бывает так: перед вами ставят задачу, а вы не в силах не то что приступить к её выполнению, но даже понять — чего от вас, собственно, хотят. Не стоит пенять на свой интеллект, опыт и квалификацию: рано или поздно нечто подобное случается с каждым, так уж устроено человеческое общение.

Не стоит ломать голову, отчего это происходит, — лучше сосредоточиться на том, чтобы с честью выйти из ситуации.

Само определение слова «требования» (англ. requirements. — Ред.) может существенно варьироваться в зависимости от вида деятельности, масштаба и стиля работы вашей фирмы.

  1. Возможно, вам выдадут подробное и тщательно проработанное техническое задание — так любят делать в крупных корпорациях.
  2. Или вам придётся изучать увесистый томик разглагольствований о том, какая работа вам предстоит и что было сделано ранее (как-то раз я битый час просидел на собрании, посвящённом единственному вопросу: как подписать кнопку — «Перезапуск» или «Перезагрузка»).
  3. А может, в среду вечером улыбчивый шеф похлопает вас по плечу и как бы невзначай попросит до пятницы обкашлять небольшой вопросик: «Да там дел-то на минуту!»

В любом из описанных случаев разработчикам так или иначе предстоит устранить какую-то проблему. В этом и состоит их работа. И чтобы успешно её выполнить, первым делом нужно убедиться, что вы правильно понимаете её суть.

При этом вы можете столкнуться с вопросами, ответить на которые не поможет ни ТЗ, ни личный опыт. Возможно, вам придётся обратиться за советом к коллегам, начальству, заказчику, бизнес-аналитику и даже собственной бабушке. Это нормально — так вы соберёте и обработаете разрозненные знания и приобретёте нужные скиллы.

Описанный ниже алгоритм не догма; более того, полное прохождение всех этапов потребуется лишь тогда, когда вы имеете дело с действительно комплексной и многосоставной задачей. Так что не пытайтесь слишком формализовать процесс — каждый из этапов помогает всего лишь быстрее разобраться в проблеме, но ни в коем случае не ограничивает вас! Это просто полезные советы о том, как действовать в непонятной ситуации.

Сначала поймите, что именно от вас требуется. Подчёркиваю: ещё не время думать о том, как вы будете выполнять поручение. Лучше обмозгуйте возможные последствия своих действий, а главное — разберитесь, чего от вас ожидают. Вот несколько простых приёмов.

Установите, какого рода работу нужно сделать для решения проблемы. Например:

  • исправить ошибку;
  • добавить новую функцию;
  • разработать новое приложение;
  • провести исследование;
  • повысить производительность;
  • что-то ещё.

Этот этап особенно важен, когда требования расплывчаты. Допустим, вам говорят: «Нужно найти способ очистить кэш пользователей после обновления веб-сайта». Интерпретировать эту задачу можно по-разному:

  • настроить очистку кэша так, чтобы пользователи всегда видели свежие обновления;
  • проанализировать все способы хранения кэша и выявить лучший вид его очистки после каждого обновления сайта;
  • найти и устранить ошибку, мешающую очистке кэша;
  • и так до бесконечности.

Если вы не уверены, что конкретно подразумевалось в задании — лучше уточните детали перед тем, как его выполнять.

Кадр: фильм «Джобс: Империя соблазна»

Желательно — в одном-двух предложениях. Представьте, будто вы составляете план работы на день. Не исключено, что ужать все требования до пары фраз будет непросто — в таком случае разбейте задачу на несколько подзадач. По сути, этот этап покажет, насколько проста задача и понятна ли вам её интерпретация.

Удачный вариант формулировки: «При обновлении сайта присваивать каждому файлу уникальный номер — так, чтобы браузер загружал только свежий код».

Неудачный вариант: «При обновлении сайта присваивать каждому файлу уникальный номер для того, чтобы браузер загружал только свежий код. Также нужно передать сообщение CDN о необходимости обновлять файлы. Кроме того, добавить обновления для приложений на iOS и Android. Затем…»

Очевидно, что второй вариант не соответствует требованию лаконичности: несколько задач слились в одну, тогда как разумнее было бы передавать их в работу по отдельности.

Теперь вам необходимо составить список основных действий в любой удобной форме. По-прежнему будьте лаконичны: не стоит расписывать пошаговое руководство по решению проблемы, просто вкратце изложите главные шаги.

Помните: на этом этапе вы анализируете стоящую перед вами задачу. Поэтому очень рекомендую записать свой план. Лично я пользуюсь заметками в телефоне.

Допустим, вам поручили настроить таргетированную рекламу продуктов в соответствии с предпочтениями каждого пользователя. Тогда алгоритм ваших действий может выглядеть так:

  • Сегментировать существующую рекламу в зависимости от пользовательской метрики.
  • Найти способ, с помощью которого маркетологи смогут сопоставлять новую рекламу с данными о пользователях (без кода!).
  • Собирать метрики пользователей, актуальные для рекламы.
  • Разработать систему, выдающую таргетированную рекламу в соответствии с ID пользователя.

Прелесть такого списка — в наглядности. Его можно быстро обсудить с коллегами или начальником. Допустим, вы показали его тимлиду, и он посоветовал вам добавить ещё один важный пункт: у пользователей должна быть возможность отказаться от рекламы. Логично: мы же не хотим раздражать любимых пользователей!

Результат — налицо: ещё до того, как приступить к программированию, мы проанализировали важную проблему и распланировали действия для её решения. Таким образом, взяв паузу и тщательно всё взвесив, мы сэкономили часы или даже дни будущих лишних трудозатрат.

Возможно, в некоторых из вас сейчас проснётся скептик: мол, в серьёзном бизнесе все требования, перед тем как попасть к разработчикам, должны анализироваться по умолчанию! Не соглашусь: к сожалению, наш мир несовершенен, и перед разработчиками нередко ставят не вполне конкретные задачи — так что умением объективно оценивать требования должен обладать каждый.

Кадр: сериал «Кремниевая долина»

Для этого ответьте на простые вопросы:

  • Кому и зачем будет нужно то, что я сделаю?
  • Какую реальную или потенциальную глобальную проблему я пытаюсь решить?

Здорово, если ответ ясен сразу. В примере с кэшем можно сказать: «Пользователи всегда будут видеть последние обновления». В примере с рекламой: «Пользователи будут видеть только те объявления, которые могут их заинтересовать».

Если очевидного ответа нет — вероятно, пришло время спросить кого-то со стороны. Так вы либо получите более чёткое представление о поставленной задаче, либо переосмыслите стоящие перед вами требования.

Надеюсь, ценность любого из ответов ваших собеседников очевидна. Более глубокое понимание проблемы и цели поможет вам принимать правильные решения не только для разработки, но и для бизнеса в целом. Выявляя неудачные решения или несущественные трудности, вы экономите усилия, которые могли бы быть потрачены впустую.

На данном этапе у вас уже должно быть понимание, что вы собираетесь делать и зачем. Необходимо лишь обдумать детали: как делать и почему именно так.

Вероятно, кто-то посчитает этот шаг избыточным: действительно, он актуален в основном для новичков в команде или для тех, кто работает в крупной компании. В этих случаях вероятность встретить незнакомый термин в требованиях значительно возрастает.

Под терминами я подразумеваю, например, коммерческие понятия — обозначения продуктов, заказчиков или процессов. Или термины, связанные с разработкой, — утилиты, приложения, модели, сервисы, библиотеки.

Убедитесь в том, что понимаете все основные понятия чётко, без неопределённостей, двойных трактовок и разночтений. Только тогда вы можете быть уверены в правильности выполнения задачи.

Кадр: сериал «Компьютерщики»

Возьмём наш пример с кэшем. Скорее всего, вы знали, что для решения проблемы было необходимо найти способ доступа к собранной информации о пользователях. Но знаете ли вы, что значит «добавить её к DAO»?

Во втором примере вы, вероятно, догадались, что нужно отформатировать данные о рекламе. Но понимаете ли вы, что такое MADF (marking advertisement data feed)? Я тоже нет. Вот почему так важно иметь ясное представление о необходимой терминологии. Незнание понятий увеличивает риск ошибок.

Реализация этого пункта зависит от того, где вы работаете, и от вашей непосредственной задачи. Бывает, что перед вами ставят только конечную цель — разработать определённую функциональность, не конкретизируя, как это сделать. А где-то пошагово распишут необходимые действия. Скорее всего, вы сталкивались и с тем, и с другим.

Если у вас нет конкретных инструкций, то предпринимать какие-то действия по данному пункту, конечно, сложно. Если есть — изучите их. Не спешите делать вывод, что всё и так очевидно. Важно понимать не только что делать, но и когда это делать.

Получив задание, мы поддаёмся естественному желанию углубиться в его детали, не убедившись, что осознаём его смысл. Однако такой подход не всегда приводит к хорошим результатам. Попробуйте сначала обдумать проблему: это позволит вам более чётко представлять цель и пути её достижения.

В этом пункте объединены первый и второй этапы нашего плана. Выполняя первый шаг, вы концентрировались на главных целях и ожидаемых результатах работы, то есть на вопросах «что?» и «зачем?». На втором этапе вы погрузились в детали, задаваясь вопросом «как?». Пришло время сравнить желаемое с действительным. Иными словами, вы можете объяснить детали, принимая во внимание общую картину, и оценить, решена ли изначальная проблема.

Спросите себя: приведут ли поставленные требования к ожидаемому результату? Действительно ли этот результат решает исходную проблему?

Если вы утвердительно ответили на оба вопроса и уверены, что все действия оправданны, — приступайте к работе. В противном случае переходите к третьему шагу, который поможет вам разрешить конфликт.

На данном этапе вы уже должны ясно понимать проблему и её решение. Осталось убедиться в его правильности.

В теории создание максимально качественного продукта предполагает свободу мнений. Каждый член команды должен иметь возможность высказаться против неоправданных для результата действий.

Однако вряд ли стоит возражать необоснованно. Нельзя просто сказать «мне не нравится» или «я чувствую, что здесь что-то не так». Необходимо тщательно обдумать ситуацию и сформулировать конкретные аргументы.

Выделим несколько основных правил при выражении несогласия.

Кадр: сериал «Кремниевая долина»

Убедитесь, что ясно понимаете, с чем не согласны. Не стоит ставить под сомнение вещи, в которых вы ещё не до конца разобрались. Если вы не можете чётко обозначить проблему и возможное решение или доказать свою точку зрения — значит, вы пока не готовы к дискуссии. Возражения уместны только при максимально детальном понимании ситуации. В противном случае советую вернуться к предыдущим пунктам и восполнить существующие пробелы.

Отбросьте субъективность. Сосредоточьтесь на конкретных вопросах. Фраза «мне не нравится такое решение» субъективна, она не отражает объективной причины проблемы. Лучше сказать: «Количество задействованных операций вызовет проблемы с производительностью».

«Раньше я делал это по-другому» или «я бы применил немного другое решение, просто потому, что так вижу» — тоже субъективные суждения.

Будьте готовы аргументированно объяснить вашу позицию. Вправе ли вы заявлять о некорректности чего-либо, если не можете обосновать, почему уверены в этом? Поэтому рекомендую записать все существующие, на ваш взгляд, ошибки и предложить решение. Если же оно не найдено — чётко заявите об этом в самом начале.

Подумайте несколько раз, прежде чем выразить несогласие с коллегами. Внимательно слушайте, что говорят другие, обдумайте ситуацию. Не жалейте на это времени!

Если вы следовали моим советам от начала до конца, то, скорее всего, хорошо понимаете задачу. Однако будьте готовы к тому, что всё же могли что-то упустить.

Я предпочитаю начинать разговор с фразы: «Я не говорю, что не согласен с вами, я просто не до конца понимаю». Уже потом при необходимости может возникнуть дискуссия — и это совершенно нормально. Хуже будет, если вы станете спорить, даже не понимая предмета спора.

Как проверить обоснованность ваших возражений? Убедитесь, что они отражают хотя бы один из перечисленных недочётов:

  • техническое решение основано на устаревшей информации;
  • техническое решение некорректно;
  • задача или решение нелогичны;
  • техническое решение не полностью удовлетворяет поставленным требованиям.

Рассмотрим подробнее каждый пункт. «Основываться на устаревшей информации» не означает что-то зазорное. На самом деле новые данные могли появиться уже после того, как было найдено решение проблемы. Или, например, никто не знал, что система, способная совершать необходимые для выполнения задачи действия, уже существует.

Техническое решение можно считать некорректным, если оно сформировано исходя из недостоверной информации. Например, SEO-специалисты поставили перед вами задачу проиндексировать авторизованную страницу в разработанном приложении с помощью поискового бота Google. На самом деле у Google нет такой функции, следовательно, SEO-специалисты располагали некорректной информацией.

Говоря о нелогичности задачи или решения, мы ставим под вопрос их целесообразность в принципе. Мой опыт разработчика показывает, что подобные требования чаще всего характеризуются формулой «создай одно в ущерб другому». Как правило, такие задачи нельзя назвать адекватными, так как они негативно сказываются на результате.

Наконец, техническое решение может быть незаконченным специально. Начиная работу над проектом, разработчики ПО часто прибегают к созданию так называемого минимально жизнеспособного продукта (от англ. MVP — minimum viable product). Другими словами, на первоначальном этапе разработки они намеренно игнорируют второстепенную функциональность и делают упор на ключевую.

Учитывая это, заявлять, что техническое решение не удовлетворяет требованиям, можно в двух случаях:

  • срок на выполнение задачи вышел, а результата нет;
  • предполагаемых действий недостаточно для создания работающего продукта или функции.

Помните: не стоит воспринимать буквально описанный мной метод. В первую очередь он призван помочь вам справиться с проблемой как можно быстрее. Возможно, будет достаточно набросать несколько записей в заметках телефона, а затем при необходимости обсудить с коллегами детали вашего задания. Вот и всё!

Шаг 1. Анализ

  • Классифицируйте задачу.
  • Кратко сформулируйте задачу.
  • Наметьте план действий.
  • Определите проблему.

Шаг 2. Конкретизация и оценка

  • Уточните терминологию.
  • Определите задачи.
  • Оцените решение проблемы.

Шаг 3. Критическое мышление

  • Не спешите возражать.
  • Выражайте несогласие правильно.
Бесплатный курс по Python ➞
Мини-курс для новичков и для опытных кодеров. 4 крутых проекта в портфолио, живое общение со спикером. Кликните и узнайте, чему можно научиться на курсе. Смотреть программу