Ликбез по техническому заданию / Хабр
Польза: получите знания о том, что такое ТЗ и как его составить. Обогатите словарный запас словами: концептуальная модель, data flow, mind card, user flow. use cases, wireframes, ER-model, client-server, API.Для кого: начинающим разработчикам и желающим чтобы их поняли (заказчикам, стартапам и менеджерам).
Время чтения: 7 минут.
Отправная точка — требования
Хочу пирожное, потом морожное!
Вовка в тридевятом царстве
Существует распространенное заблуждение, что достаточно сказать: “Нужно приложение для музея/кошки/завода” и сразу станет понятно, что вам необходимо.
К сожалению, все не так просто. Представьте, что вам нужно построить дом. Вы идете к строителю, и он приступает к работе. Вы не предоставили ему ни чертежей, ни участка, даже не сказали какого цвета должен быть забор. Но дали на все про все полгода и значительную сумму денег. Спойлер
Через полгода вас ожидает нечто в поле и вообще с забором серобуромалинового цвета.
Жутко правда? Бюджет уже потрачен и срок истек.
Чтобы такого не произошло все требования к продукту фиксируют, это и есть то, с чего начинается любая разработка.
Удобный вид требований — ТЗ
Замесить и нарубить!
Вовка в тридевятом царстве
Хорошо. Будут требования. Теперь вас точно поймут разработчики. Но тут возникает подводный камень №1: человечество пока не научилось читать мысли. Поэтому нужно в каком-то виде передать информацию и лучший для этого способ — Техническое задание.
Его также называют ТЗ, SRS, PRD — все это названия документа, в котором в правильной форме зафиксированы требования к продукту.
Подводный камень №2: память человека не безгранична, всегда лучше иметь одно место, где все ваши пожелания и требования зафиксированы (не переписка в telegram или звонок по телефону). Поэтому ТЗ это печатный текстовый документ с приложением схем и инфографики, не написанный от руки или сфотографированный. Лучше всего в формате .PDF или Google Docs.
Рецепт грамотного ТЗ
Техническое задание для разработчиков это своеобразный рецепт приготовления успешного продукта. Успешный продукт — тот, который легко поддерживать, можно развивать и менять, он не развалиться при смене разработчика и приносит прибыль в любом ее виде. Вы хотите, чтобы ваш проект был полноценным? Отлично. Напишите для этого хороший рецепт. Классическими ингредиентами (по международному стандарту IEEE-830) служат:
- Концептуальная модель
- Функциональная карта
- Путь пользователя
- Пользовательский интерфейс
- Программные интерфейсы
- Нефункциональные требования
Последние 2 пункта специфичны, советую на них обратить внимание читателям близким к разработке.
Ниже я разберу подробно каждый из пунктов. Для тех, кому не хочется подробно разобраться, оставляю ссылку на международный стандарт c шаблоном технического задания: ссылка на документ.
Концептуальная модель
В этот пункт входит краткое описание продукта, в нем отражается цель проекта и его отличительные черты.
Например: “Приложение для знакомств, в котором можно смотреть короткие видео в профилях пользователей и общаться в чате”.Также не помешает сказать пару слов об аудитории продукта, так команда проекта сможет понять его особенности и дать вам несколько полезных советов. Расскажите о ее возрасте, характере и территориальном расположении, каких-то особенностях, которые должны отразиться на проекте.
Например: “Это молодые люди, выезжающие за рубеж для отдыха и интересующиеся общением за пределами языкового барьера, которые любят снимать фото и видео”.
Стоит рассказать о типах пользователей и их ключевых отличиях.
Например: “В приложении должны быть обычные пользователи и модераторы, которые получают жалобы от пользователей на контент или профили. Модераторы могут просматривать чат обычных пользователей после жалобы и заблокировать в сервисе нарушающий правила аккаунт”.
И в завершении расскажите о компонентах вашего продукта.
Например: панель администратора, которую используют модераторы; мобильное приложение, которое использует пользователь, чтобы зарегистрироваться, добавить контент, поучаствовать в чате и т.д.
Высшим пилотажем будет сделать так называемый data flow или контекстную диаграмму, в которой будет отражено как пользователи взаимодействуют с продуктом, его компонентами и между собой.
Функциональная карта
Функциональная карта отображает общую концепцию проекта с уровнем детализации необходимым для того, чтобы оценить объем работ, расставить приоритеты.В традиционном формате такая карта напоминает карту сайта. Но удобнее всего ее отобразить в виде mind card (майнд карт, интеллект карт). Часто менеджеры рисуют на совещании на доске или листе бумаги слова и между ними связи, так вот, это и есть майнд карта. Это можно сделать удобно в бесплатных сервисах (coggle, draw.io и mindmeister) или просто в Office Word.
Например: “В приложении должна быть регистрация по почте, создание и заполнение данных профиля,, возможность загрузить и отредактировать фото и видео, список аккаунтов других пользователей с различными типами фильтров, текстовый чат, обращение к службе поддержки.
Путь пользователя
Так называемый user flow или путь пользователя, это последовательный список действий или экранов, по которым может переходить пользователь в процессе взаимодействия с продуктом. Опишите, как в вашем представлении будет взаимодействовать с продуктом пользователь. Очень удобно это можно сделать также майнд картой или просто списком действий. Например: “Пользователь заходит в приложение, чтобы познакомиться с сверстниками. Он заполняет свой профиль данными и загружает фото и видео. Затем пользователь заходит в ленту и фильтрует ее по каким-либо критериям. В качестве результата он получает список релевантных профилей, может посмотреть их и написать другому пользователю в чате.
Путь пользователя — это общий алгоритм работы с продуктом. Также существует еще use cases (варианты использования) — это детализация user flow. В случае мобильного приложения для знакомств вы создали путь пользователя по экранам, а затем описываете, что пользователь может сделать на каждом экране.
Например: на экране регистрации пользователь может:
перейти на экран авторизациизарегистрироваться через соцсети (Facebook, Twitter)может ввести почту, пароль, затем его повторить и подтвердить регистрацию в письме, пришедшем на почту.
Пользовательский интерфейс
Продукт должен мало того что работать, так еще и приятно выглядеть. Немного отойдем от тематики приложений, чтобы не заставлять вас их скачивать для ознакомления. Лучше посмотрим на симпатичные сайты:
Посмотрели на пример плохого дизайна, теперь вытрите кровь с глаз и перейдем к обсуждению интерфейса. В этой части технического задания стоит приложить реферы — примеры того, каким вы хотите видеть свой продукт. Это могут быть аналоги похожих разработок или просто примеры, дизайн которых вам понравился.
Опишите в общем виде, каким вы хотите видеть свой продукт, какие у него должны быть цвета, какие элементы использоваться, какую вы хотите анимацию и т.д. Если у вас есть фирменный стиль или брендбук, отлично, сошлитесь на них.
Дизайнеры скажут вам большое спасибо, если вы укажите стиль дизайна интерфейса, например flat design или material design.
Высшим пилотажем будет добавить wireframes (вайрфреймы) — прототипы интерфейса продукта в виде приближенных схем.
Программные интерфейсы
Этот раздел для специалистов. Если вы уверены в своих силах, то продолжайте чтение.В лучшем техническом задании также описывается архитектура продукта, то есть то, из каких программных компонентов он состоит. В случае клиент-серверного приложения для знакомств сервис разбивается на часть сервера, которая хранит данные и обрабатывает их, производит какие-то логические операции и часть клиента, который отображает данные.
Сервер декомпозируется на модули: базы данных, аутентификации, чата и т.д.Клиент связывается с сервером через API (интерфейсы передачи данных), стоит указать его тип (REST, WEB, RPC и т.д.) и описать методы, ответы и обработку ошибок.
Данные обычно хранятся в базе данных в виде специальных структур, чаще всего таблиц (для реляционных БД) и json структур (для нереляционных). Разработчики скажут вам огромное спасибо, если в техническом задании вы укажите сущности базы данных (ER-модели) и опишите хранимые поля, с указанием их типов данных (string, int и т.д), ключей (primary, foreign), обязательности (required) и пустого значения (nullable).
Нефункциональные требования
Это общие требования к продукту. Их можно разделить на требования к техническому обеспечению, требования безопасности и требования к производительности.В требованиях к техническому обеспечению указывают пожелания к устройствам и операционной среде, например для приложения знакомств это Android 7.0+ и JDK 8+, iOS 11.0+ и Swift 4.2.
В требованиях к безопасности можно указать, что передача данных в чате должна осуществлять с помощью шифрования SHA-1 и что при регистрации сложность пароля должна быть не менее 8 бит.В требованиях к производительности говорится о связи компонентов и отказоустойчивости, например стоит указать, что таймаут на чтение сообщения в чате не более 1 с и что приложении частично хранит кеш и может ограниченное время работать в автономном режиме.
Советы
- Создавайте текстовый документ в онлайн офисе или PDF, который легко будет прочесть. Это гораздо лучше переписки в чате или голосового сообщения, его всегда можно будет посмотреть с любого устройства.
- Соблюдайте последовательность, переходите от общих требований к частным, приведенная выше структура не идеальна, но может служить хорошей основой.
- Все требования должны быть в одном документе или вики-структуре, не храните их отдельно, они должны быть всегда доступны из одного источника.
- Давайте четкие и разумные указания, избегайте неточностей, пишите максимально простым языком.
- Описывайте ваши требования максимально подробно. Лучше один раз все продумать, чем постоянно уточнять различные детали и нюансы.
- Приготовьтесь потратить больше нескольких дней или обратитесь к профессионалу для составления документа. Грамотное техническое задание спасет вас от долгих обсуждений деталей с разработчиками и обозначит четкие критерии сдачи проекта. Например, полноценное ТЗ по стандарту IEEE-830, приложенное к договору на разработку, является аргументов в суде в случае невыполнения требований.
Ликбез по техническому заданию — Карьера на vc.ru
Получите знания о том, что такое ТЗ и как его составить. Обогатите словарный запас словами «концептуальная модель», data flow, mind card, user flow. use cases, wireframes, ER-model, client-server, API.
Для кого: начинающим разработчикам и желающим, чтобы их поняли (заказчикам, стартапам и менеджерам).
Время чтения: 7 минут.
Отправная точка — требования
Хочу пирожное! А потом морожное! …. А что это, вы и есть за меня будете?!
Вовка в тредевятом царстве
Product Owner
Существует распространенное заблуждение, что достаточно сказать: «Нужно приложение для музея/кошки/завода» и сразу станет понятно, что вам необходимо.
К сожалению, все не так просто. Представьте, что вам нужно построить дом. Вы идете к строителю, и он приступает к работе. Вы не предоставили ему ни чертежей, ни участка, даже не сказали какого цвета должен быть забор. Но дали на все про все полгода и значительную сумму денег. Через полгода вас ожидает нечто в поле и вообще с забором серобуромалинового цвета. Жутко правда? Бюджет уже потрачен и срок истек.
Чтобы такого не произошло все требования к продукту фиксируют, это и есть то, с чего начинается любая разработка.
Сбор требований
техническое задание на сайт или концепция? / Хабр
Если Вы читаете эту страницу и являетесь руководителем компании или маркетологом, значит, находитесь гораздо выше уровня «сделайте мне как у этих». И скорее всего, уже не первый раз меняете облик своего сайта.
О разработке ТЗ на Хабре было много статей. Нужно ли оно, как оно должно быть сделано в студии и т.п.
Я хочу показать, что перед созданием именно технического задания во многих случаях имеет смысл сделать еще один документ.
Для начала разберемся с терминами. Это важно!
Техническое задание — это документ, разработанный заказчиком и утвержденный исполнителем. В нем изложены требования, параметры и основные эксплуатационные характеристики проекта, объекта или системы.
Чувствуете разницу? Разрабатывать техзадание должен именно клиент, а не веб-студия! И утверждает ТЗ именно студия, а не заказчик!
В реальности большинство ТЗ на сайт представляет собой внутренний документ веб-студии, в котором техническим языком описаны основные термины, модули и прочие составные части сайта.
Беда этих технических заданий именно в «техничности». В процессе создания сайта участвуют как минимум: заказчик или его представитель, менеджер студии, дизайнер, верстальщик, программист.
Каждый из них говорит на своем языке, который другим непонятен. Получается конфликт однозначного понимания требований к сайту. Кстати, этот момент во многих договорах нивелируется пунктом «заказчик не вправе ссылаться на неоднозначность ТЗ».
А ведь еще есть и конечный пользователь! Про него в контексте ТЗ никто не думает вообще.
Именно поэтому для передачи разработчику стоит сделать упрощенный для понимания всеми сторонами документ. Наглядный. По сути, это готовый сайт на бумаге. Он лучше помогает понять, что именно с точки зрения бизнеса хочет получить от сайта заказчик, и что нужно посетителю. И объяснить это «на пальцах» веб-студии.
Несомненно, для создания такого документа нужен специалист со стороны, у которого есть компетенции и в сфере продвижения продуктов/сайтов и в сфере бизнес-аналитики. Такой специалист сможет быть «переводчиком» с технического языка на языка бизнеса и наоборот.
В чем отличие ТЗ и концепции
Главное отличие в детализации. Если в техническом задании больше упор именно на подробности с точки зрения кода, то концепт оперирует целями, задачами бизнеса с точки зрения интернета, и содержит аналитику ниши, и обоснование структуры, внешнего вида страниц, их содержание и взаимодействие сайта и пользователя.
То есть концепция – это модель работающего сайта в картинках в контексте бизнеса, которая понятна всем участникам процесса. Причем, модель уже включает стратегию продвижения и рекламы.
На основании уже этого документа студия разрабатывает свое внутреннее ТЗ.
В чем плюсы: конечный продукт – сайт – является частью бизнес-процессов компании, а не как обычно все по отдельности.
И концепт является основой не только для ТЗ, но и для маркетинговой стратегии.
Перед созданием концепции
Первое, с чем нужно определиться, это с объемом аудитории, для которой мы создаем сайт.
К примеру, нет смысла создавать сложный и подробный интернет-магазин автозапчастей для «ГАЗелей», если вы работаете только в своем регионе, а число машин в нем исчисляется несколькими сотнями. Вряд ли найдется много желающих ежедневно пользоваться вашим сайтом.
В данном случае одним из вариантов решения будет одностраничник со скачиваемым каталогом запчастей или складских остатков.
То есть одна из задач концепции – выбрать оптимальное решение (на данный момент). Сэкономить деньги и время на разработку.
Основное содержание концепции:
- Определить цели. Зачем мы создаем сайт и какие результаты (в цифрах – посещаемость, продажи, звонки) от него ожидаем.
- Определить задачи. Что нужно сделать, чтобы достичь указанных выше целей.
- Определить целевую аудиторию и действия. Здесь речь идет о регионе, в котором вы работаете, секторе экономики и о том, чего ждете от посетителей на сайте (чтобы оформил заказ, позвонил, написал). Действия нужно определить, чтобы их можно было посчитать в системах аналитики.
- Изучить статистику спроса в поисковиках на ваши услуги/продукцию. То, как ищут вас люди, станет основой структуры (списка страниц и разделов) вашего сайта.
Кроме того, объем спроса (популярность) покажет, чему на сайте нужно уделить больше внимания, а чему меньше. К примеру, если отзывы о вашей продукции ищут всего 50 человек в месяц, то хватит для них одной странички, а если их ищет несколько тысяч – имеет смысл создать полноценный раздел, где для каждого отзывы своя страница. - Собрать все материалы для сайта – поймем, чего не хватает и сможем ли подготовить эту информацию для передачи разработчикам. Если нет, корректируем структуру и содержание типовых страниц.
Еще один важный момент, почему информация должна быть готова до создания дизайна. Разработчик почти никогда не представляет, какие именно тексты, видео, фото будут на вашем сайте, а потому делает дизайн так, как считает нужным. В итоге под те же отзывы дизайнер отведет места меньше, чем на самом деле требуется, а сам дизайн «развалится». - Отрисовать все типовые страницы сайта (главная, контакты, отзывы, каталог и его разделы, карточка товара и т.п.) и описать принцип их работы и взаимодействия с посетителем.
- Изучить конкурентов. Это поможет дополнить структуру или навести на новые мысли об оформлении страниц сайта.
Создание прототипов страниц — это ключевой момент в концепции. Он является итогом всех изысканий и аналитики, подготовки контента и прочего. Поэтому без примера хотя бы одного прототипа этот пост будет незаконченным.
Пример описания прототипа одной из страниц сайта
Детализация описания на первом этапе может быть любой, т.к. и разработка сайта и разработка ТЗ это процесс итерационный — сделали предположение, обсудили, внесли правки. Приведенный ниже пример — всего лишь пример (2013 год).
Описание пунктов:
- Подчеркиваем, что это монобрендовый магазин с ценами фабрики.
- Контакты выносим в отдельный блок, т.к. по статистике предыдущего сайта пункт был одним из наиболее кликабельных. Показываем режим работы, чтобы снизить число пропущенных звонков. Корзину смещаем наверх, чтобы не мешать ссылку на контакты и телефон с данными о товарах.
- По статистике сайта поиском пользуются активно, в том числе и менеджеры при поиске по артикулам.
- Основное меню имеет смысл сделать выпадающим, т.к. учитывая количество вложенных разделов, вертикальное меню может стать «портянкой».
- Для слайдера нужно предусмотреть сортировку. В правой части слайдера размещаем блок, отображающий число слайдов.
- Онлайн-консультант – всплывающее окно по клику
- Сквозной блок о доп. услугах. Информация для покупателя, чтобы ее можно было получить на любой странице.
- Текст, раскрывающий преимущества магазина и мебели, и одновременно описывающий страницу для поисковиков.
- Просмотренные ранее товары. Если посетитель впервые на сайте, показываем популярные товары.
- Блок футера: адрес, телефоны, дублирующее меню.
Итоги
Я занимаюсь разработкой подобных документов практически с самого начала работы с сайтами, т.е. с 1998 года. На создание первой версии такого концепта уходит 1-2 дня в зависимости от сложности проекта и используемых инструментов (иногда проще даже на бумаге сделать отрисовку).
Эффективно использование такого подхода для проектов с 50 страницами и более.
Что это дает:
- Ставит на место голову с точки зрения «что хочу я, что хочет мой клиент».
- Документ становится основой для маркетинговой стратегии.
- Разговор всех участников процесса идет на одном языке.
- Исключается вариант, когда в итоге получается компания отдельно, сайт отдельно. Сайт является частью бизнес-процессов предприятия.
- Сильно экономит время на больших и сложных проектах.
- Заметно удешевляет проект и сокращает число переделок — а значит, вы запуститесь вовремя и не выйдете за пределы бюджета.
Готов поделиться с читателями примерами таких концептов. Кстати, как результат: yavitrina.ru
Такой итог может получиться, если сделать и концепт и грамотное ТЗ для команды разработчиков.
ТЗ высокой четкости / Хабр
Я аналитик, который пишет непонятные ТЗ. Т.е. я пытаюсь писать очень понятные ТЗ. В целом, я слушаю клиентов, потом я слушаю разработчиков, потом голоса в своей голове. Зачем я говорю с ними? В общем, получается то, что получается. Ну вы поняли.Написать идеальное ТЗ проще простого:
1. Договорился о минимальном этапе (на 2-4 недели).
2. Описал юзер-стори по шагам.
3. Составил список экранов будущей системы.
4. Прописал названия методов API и форматы данных.
5. Запросил тестовый контент и составил таблицы с тестовыми данными.
6. Сформулировал из всего этого цели и задачи.
7. Согласовал план работ и выставил задачи в таск-менеджер.
Но не тут-то было! Давайте я расскажу, как все происходит в реальной жизни, а также поделюсь своими лайфхаками, как я с этим справляюсь.
Скан салфетки (Что это мы нарисовали на встречке?)
Тот момент, когда у заказчика в кафе кончился словарный запас, и он прешел к изобразительному искусству. Так появляются карты наступательных операций по захвату мира прямо на салфетках. Не всегда везет присутствовать при этом лично, тогда в вотсапе сваливается фоточка салфетки в изометрической проекции в рубрику “без комментариев”.
Лайфхак: “Как ты к этому пришел, приятель?”
Клиенту сложно сформулировать, что он задумал. Сложно продумать все возможные варианты работы системы, поэтому я часто прошу его рассказать о своей жизни и о том, как же он пришел к этим великим идеям. Обычно, после этого рассказа, как минимум, можно понять основные цели и задачи, ведь теперь мы знаем, из какой реальности к нам пришли эти демоны.
Извращенная логика
Открываем ТЗ и видим, что бы вы думали? Портал с виртуальным кладбищем:
* поднять захоронение в топ 100;
* поделиться захоронением с другом;
* отправить захоронение на главную;
* добавить в некрополь;
* добавить захоронение в черный список;
* активировать карту вип-пользователя;
* установить антивирус;
* кастинг;
* групповые склепы со знаменитостями.
Лайфхак: “Правильно ли я вас понял?”
Иногда заказчик настолько увлечен своими гениальными идеями, что не в силах признать нарушения в логике. Если вы напрямую укажите на логические противоречия, то клиент скажет, что никаких логических противоречий нет, а вы просто не слушаете о чем вам говорят, и делать будем именно так. Решено!
А всего-то, ему нужно услышать свои мысли немного другими словами:
— Правильно ли я понимаю, что вы хотите сделать кастинг захоронений?
— Правильно ли я понимаю, что пользователи будут выводить склепы в ТОП-100?
— Я правильно вас услышал, что пользователи будут приглашать друзей в братские могилы?
— Правильно ли я понимаю, что пользователи будут добавлять могилки в “черный список”?
— Правильно ли я понимаю, что знаменитости мечтают вписать в групповые склепы?
Т.е. вы не критикуете, не сопротивляетесь, не спорите, просто уточняете.
Все и так понятно (прочитайте мои мысли)
— Зарегистрируйся в нашей системе и стань известным и успешным.
— А что нужно делать, дальше?
— Ну вот ты зарегистрировался первый шаг уже сделан!
— ОК, а какой второй шаг?
— Ну активируй карту и подними свою анкету в топ-100.
Иии? Очень хочется услышать рецепт до конца!
Лайфхак: “А что если?”
Ха! Все было бы идеально, если бы заказчик вменяемо отвечал на заданные вопросы. Не спорю, многие отвечают, но есть и те, чьи ответы ничерта не проясняют. С ними нужно немного по-другому. Им нужно нарисовать сценарий в виде вопроса:
— А что, если пользователь зарегистрировался, активировал карту, поднял анкету, но не стал известным и успешным?
Описание математики рисунком
Денежка идет отсюда вот сюда, тут маленькая стрелочка, а тут процентики, сюда эти баллы, а туда эти баллы. Прямо железнодорожный вокзал на листке бумаги!
Лайфхак: “А давайте посчитаем это в XLS”
Когда я вижу что-то похожее на математику, но без контрольного примера, мне сразу становится страшно, ведь я хорошо себе представляю, что мне скажут разработчики до и в процессе разработки.
При этом просто попросить контрольный пример не получается. Если бы заказчик мог сделать контрольный пример, он бы его сделал и не занимался бы изобразительным искусством. Поэтому контрольный пример придется делать вам как минимум в “Экселе”. Не всегда хватает “Экселя” — возможно, потребуется MathLab или же полноценный исследовательский этап, если у вас внезапно нарисовался DSP, или 3D расчеты, или же распознавание образов с блэк-джеком и нейросетями.
Результатом этой работы должен быть набор тестов, который дает однозначные с точки зрения математики результаты.
Не грузи меня деталями
— Хотим стримить порно через приложение в AppStore.
— Но нас же заблокируют!
— Не грузи меня деталями!
— Хотим стримить по wi-fi аквалангистов с кораллового рифа
— А wi-fi работает под водой?
— Не грузи меня деталями!
— Хотим раздавать 4G wi-fi с автономного роутера, но только тем, кто зарегистрировался в нашей базе.
— То есть придется колхозить прошивку для роутера и ехать в Китай?
— Не грузи меня деталями!
— Хотим подключиться к базе общественного транспорта Москвы
— А вы уже договорились с DIT?
— Не грузи меня деталями!
Лайфхак: “Был тут один случай!”
Перед нами стратег, у которого свой vision, и ничто не способно остановить его движение к успеху! Какие-то мелкие детали (законы физики, современные технологии, политики платформ) их не волнуют — это все только для технических специалистов.
Однако способ достучаться до “негрузидетальных” заказчиков есть — это нарратив. Они вполне смогут услышать историю, про то как:
* На AppStore недавно забанили вашего дружбана за порнушку.
* Мужик на YouTube пытался заняться зимней рыбалкой с wi-fi экшн камерой, чтобы посмотреть как рыба реагирует на наживку (черт, я ведь не шучу сейчас!).
* Как другой ваш дружбан колхозил прошивку для роутера, а в Гуанчжоу его киданул гид.
* Как вы уже полтора года ждете ответа от DIT Москвы.
Казалось бы, что это же частные случаи, и “у нас-то все будет по-другому!” Но, как не удивительно, заказчик-стратег верит байкам, особенно тем, которые травят их друзья. Отсюда вытекает другая проблема.
Д — Дичь! (так никто не делает)
— Давайте спарсим выдачу “Яндекса”!
— ЧТОА? Эээ… Мммм… Как? Заачееем?
— Чтобы сэкономить на поисковом движке!
— Давайте для iPhone напишем три приложения которые будут внутри iPhone друг с другом взаимодействовать!
— Заааааачеееееем???
— Для повышенной безопасности: одно будет шифровать трафик, другое будет следить за обновлениями, а третье будет чатом.
Лайфхак: “Без нас”
Когда вас заставляют делать дичь, надо отказываться. Я так за всю практику ничего и не придумал, что с этим делать. Вилы в любом случае. Да, если вы отказываетесь делать Дичь, то иногда приходится увольняться, или отказываться от дохода. Но если вы соглашаетесь делать Дичь, то разрешаете превратить свою работу в ад.
Конечно, есть третий путь: можно уговорить заказчика пойти стандартным путем и сделать все правильно. Иногда мне это удается.
В целом, метод такой:
* Задать вопросы.
* Определить ценности и потребности.
* Предложить несколько альтернативных вариантов заказчику, о которых он не знал или не думал.
Дичь бывает разной степени упоротости. Если Дичь не слишком жесткая, то заказчик находит себе какую-то неопытную жертву, которая соглашается. Если Дичь чересчур, и все поголовно от нее отказываются, то заказчик прозревает, расстраивается и уходит бухать или, в самых тяжелых случаях, пробует сам учиться программированию, чтобы всем что-то доказать.
С — Схема! (как хотелось бы, но не работает)
Сэйлз выцепил клиенток из Tinder’а.
— Здесь у нас будут видеотрансляции с девушками, здесь у нас будет чат, здесь мы будем взимать деньги за голосовые звонки девушкам. Во всех чатах, и в видео, и в голосовом, у нас будут фильтры, чтобы мужчины не обменялись с девушками телефонами напрямую. А то ж все такие хитрые!
— Отлично! А вы уверены, что такой фильтр существует?
Лайфхак: “А все остальное идеально?”
Обычно, когда разработчики видят такое, то они цепляются за это мозгом и спорят с заказчиком. А нужно задать себе вопрос: “ОК, тут затык, а все остальное в этом проекте — идеально?”
Конечно же нет! Ведь причуды не ходят поодиночке. Выясняется, например, что: между соучередительницами не улажены юридические вопросы, они находятся в разных странах и ненавидят друг друга, какая-то несчастная команда уже начинала это пилить, теперь проект покоится на компакт-диске, который не читается, и нужно заняться полировкой царапин…
И тут вы сразу расслабляетесь, перестанете спорить и предлагаете заказчику вернуться к обсуждению после улаживания всех остальных вопросов.
Коллективное творчество (правка в правке в режиме правки, “Ворд” — в лоскуты)
Представьте себе миленькую международную компанию-гигантика. В ней ТЗ нужно согласовать со всеми департаментами. Нами предложены три варианта реализации. Ну, знаете, как в крупных компаниях говорят с подрядчиками? А вот так: “Предложите нам вариааанты!” (обязательно с оттяжечкой и “н” так в носик). Так вот, одним отделам понравился один вариант, вторым — второй, третьим — третий. И все так чатятся в режиме правки. Смогу ли я узнать ТЗ, которое получу на выходе после правок?
Лайфхак: “Жрем слона по частям”
Чем больше проект, тем больше вариантов реализации, больше правок, больше технических рисков, логических несрастух и недосказанности. Поэтому я всегда стараюсь уговорить заказчика на минимальный этап с минимальным функционалом. Но не всегда так можно. Конечно же, все хотят строить космолет — это же гораздо престижнее! И начинать строить космолет с капитанской рубки — это же показатель профессионализма, ведь правда же!
У меня в почте есть 18-ая, а есть даже и 23-я версия ТЗ из 6-ти страничек. Все уже настолько задолбались, что никто уже не хочет сводить это все вместе… Нестерпимо хочется в производство!
Заключение
Каков путь к идеальному понятному ТЗ? Он очень простой: никогда не начинайте работать, пока не получите хотя бы минимально информацию и материалы по всем пунктам для идеального ТЗ, которые я описал в начале. Но есть проблема: так вы никогда не начнете работать. Поэтому в реальности приходится изворачиваться по-всякому, применять лайфхаки, слушать угрозы клиентов, жалобы менеджеров и недовольство разработчиков. И Agile от этого всего не спасает, ох не спасает…
Как я писал свое первое техническое задание / Хабр
Стать менеджером IT-проекта довольно сложно. И, думаю, не у меня одного появилась проблема с написанием первого технического задания. Но, давайте по порядку. Какие знания и навыки я имел перед началом работы?На данный момент я являюсь студентом, уже закончившим 3 курс Санкт-Петербургского государственного электротехнического университета «ЛЭТИ». Учусь на кафедре автоматики и процессов управления (АПУ) по профилю информационные системы и технологии в бизнесе. Фактически из меня клепают менеджера проектов, запихивая в голову знания по базам данных, нереалиционным системам, программированию (в основном JAVA и С++ на первых курсах), процессов управления и контроля проектов.
В процессе обучения на двух дисциплинах нам уже давали собирать требования по системе и писать по этим требованиям ТЗ. Но, думаю, вы представляете, как они собирались и как проверялись. Учитывая, что все ограничения мы (студенты) придумывали сами, функционал системы был очень простой. Плюс мы не сильно парились на тему финансовой выгоды будущего продукта.
Однако из этих курсов мой были получены навыки работы с UML и в голове держался образ структуры технического задания в целом. С чего начать, что делать и к чему прийти. Это и помогло мне начать.
Что представляет собой компания, которая взяла такого недоработника и какие задачи она передо мной поставила?
На 3 курсе (а то и раньше) я уже начал понимать, что в университете мне на дадут достаточных для работы навыков, чтобы при его окончании я был полезен компании, которая меня приютит. И по-этому перед мной появилось два пути для получения достаточного количества опыта, чтобы годно нести звание руководителя IT-проектов.
Итак, о каких путях идет речь?
1. Начать свой стартап.
2. Устроится в компанию уже сейчас, работая бесплатно на опыт, пока не начну приносить хоть маломальскую пользу (рабская стажировка).
Первый вариант, несмотря на то, что идей для стартапа в голове много, отлетел сразу, как появился приблизительный ценник того, во сколько он мне обойдется. Будучи студентом ты сильно ограничен бюджетом и довольно опасно не имея опыта и даже представления, как это реально работает, вкладываться в такое дело. Прибыльным, во всяком случае, оно вряд ли ли станет.
Второй же вариант оказался идеальным для моего университета и кафедры в целом.
Дело в том, что моя кафедра сотрудничает с компанией «АЛЕЕ СОФТВЕР». Представители данной компании не только преподают у нас в вузе, предлагая студентам практические навыки и опыт, но и с удовольствием стажируют «лучших» у себя в компании. В эту компанию я и обратился.
Конечно же мне дали для начала самое простое из заданий в фирме. Цель: переписать web-клиент системы под новый фреймворк с добавлением новых функциональных возможностей.
С чего началась моя работа?
Этап 1. Для начала мне рассказали про систему. Что она собой представляет, какие проблемы она решает и как она работает. Это было что-то вроде 4-х часовой лекции по основам ERM системы и истории продукта. Далее мне дали мануал по системе, в котором я разобрался более подробно в ее текущем функционале. К слову, система имеет два клиента: web и desktop. Причем функционал второго был шире текущего функционала первого. Документация имелась только на desktop версию, да и то, как справочник по работе с системой для клиентов. Технические задания по системе были утеряны.
Этап 2. После, ознакомившись с мануалом и перечитав все записи после лекций о системе, я начал структурировать полученные знания. Целью данного шага для меня стало написание некого документа, в котором были бы написаны ответы на вопросы: «что?» (за система), «зачем?» (она создана), «как?» (она работает). На данном этапе я получил нечто вроде документа, презентующего текущий продукт. В нем описывались цели клиента, как клиенты видит эту систему и почему клиент должен купить именно нашу систему (ее особенности). Думаю, это из-за того, что по своей натуре я продажник и для меня основной вопрос «зачем это покупать?». Документ был похож на «спецификацию требований», но отличался от университетских курсовых работ, в которых мы писали спецификацию. Был написан более простым языком и не имел четких разделов. Лаконично и самое основное. Как мне показалось, его было достаточно, чтобы перейти к следующему шагу.
Этап 3. UML-диаграммы, все как «по-учебнику». На диаграмме вариантов я отобразил пользователей и что они хотели бы видеть в системе.
После, как я думаю, и пошли мои ошибки. Я сразу перешел от описания функционала, перескочив описание данных и то, как эти функции работают, к описанию интерфейсов. Из-за этого, во время описания интерфейсов появлялись логические ошибки. Не понимая, как хранятся данные, я «нафантазировал» интерфейс для web-клиента, в котором клиент получил бы самый тормозящий функционал из всех, что он видел.
Этап 4. Доработка. Последние три этапа длились около 1,5 месяца, когда четвертый этап длился больше 2. Я всех достал в офисе.
Сначала я переписывал функционал и дорисовывал интерфейсы. Так как это был мой первый проект, я не имел даже малейшего представления, что важно описать все-все ошибки, все-все иконки. Нужно, чтобы заказчик знал, что может сделать каждая кнопка в программе еще до ее написания. Мне пришлось изучить Gui-machine, программу, созданную в моей компании, в которой можно создавать динамические интерфейсы. Программа полезная, но привыкал я к ней долго. После того, как я исправил логические ошибки, нужно было править язык и структуру ТЗ. В университете на это закрывали глаза, так как проекты не превышали 50 страниц. Но тут серьезное задание и я себя переоценил. Речь была слишком простой, терялась логика в заголовках. Я постоянно скакал от функции одного актера к функциям другого. В скринах интерфейса люди терялись, переставая понимать что за чем идет.
Немного стыдно это писать. Я довольно много работал над ТЗ и вкладывал в него много сил и времени, но оно все равно оказалось сырым. Мою работу приняли, но меня перевели в отдел маркетинга.
Что я извлек для себя?
1. Я понял, как нужно писать ТЗ, чтобы оно было читабельным.
2. Увидел на что нужно акцентировать внимание.
3. Самое главное в ТЗ это структура. Ее нужно иметь везде.
И самое главное, я понял, что ТЗ пишется не для себя. ТЗ пишется для других.
Буду рад услышать ваши фейлы и неудачи в работе, когда вы только начинали и то, как вы с ними справлялись.
datetime — Основные типы даты и времени — документация Python 3.8.5
Хотя арифметика даты и времени поддерживается, основное внимание при реализации уделяется об эффективном извлечении атрибутов для форматирования и обработки вывода.
Знающие и простые объекты
Объекты даты и времени можно разделить на «осведомленные» или «наивные» в зависимости от включают ли они информацию о часовом поясе.
С достаточным знанием применимого алгоритмического и политического времени настройки, такие как часовой пояс и летнее время, объект , осведомленный о , может располагаться относительно других осведомленных объектов.Осознающий объект представляет собой конкретный момент времени, который не открыт для интерпретация.
наивный объект не содержит достаточно информации для однозначного определения местоположения относительно других объектов даты / времени. Представляет ли наивный объект Универсальное скоординированное время (UTC), местное время или время в другом часовом поясе полностью зависит от программы, так же как от программы зависит, будет ли конкретное число представляет метры, мили или массу. Наивные объекты легко понимать и работать, за счет игнорирования некоторых аспектов реальности.
Для приложений, требующих осведомленных объектов, datetime и time объекты имеют необязательный атрибут информации о часовом поясе, tzinfo , который
может быть установлен как экземпляр подкласса абстрактного класса tzinfo .
Эти объекты tzinfo собирают информацию о смещении от UTC.
время, название часового пояса и то, действует ли летнее время.
Только один конкретный класс tzinfo , часовой пояс класс , является
поставляется модулем datetime .Часовой пояс класс может
представляют собой простые часовые пояса с фиксированными смещениями от UTC, например сам UTC или
Часовые пояса Северной Америки EST и EDT. Поддержка часовых поясов на более глубоких уровнях
детали до приложения. Правила корректировки времени по
мир больше политический, чем рациональный, часто меняется, и нет
стандарт подходит для всех приложений, кроме UTC.
TZ Расширение файла — что это такое? Как открыть файл TZ?
Следующий листинг составлен из базы данных, созданной Associate This! программа, выбранные данные из основной базы данных FILExt и информация о расширениях файлов, предоставленная пользователями.
ProgramID: WinZip, FileType: WinZip File, AppName: WinZip
EXEFile: winzip32.exe
ProgramID: WinZip, FileType: WinZip File, AppName: WinZip Executable
EXEFile: winzip32.exe
ProgramID: StuffIt.Tar.Archive.View
EXEFile:% ProgramFiles% \ Aladdin Systems \ StuffIt \\ stuffit.exe -view% 1 -from_shell
ProgramID: Winamp.File
EXEFile:% ProgramFiles% \ Winamp \ winamp.exe% 1
ProgramID: WinZip
EXEFile:% ProgramFiles% \ SHAREW ~ 1 \ WINZIP \ winzip32.exe% 1
ProgramID: WinZip
EXEFile:% ProgramFiles% \ WINZIP \ winzip32.exe% 1
ProgramID: ZipZag.tz
EXEFile:% ProgramFiles% \ ZipZag \ zipzag.exe% 1
ProgramID: WinZip
EXEFile:% ProgramFiles% \ WINZIP ~ 1.1FR \ winzip32.exe% 1
ProgramID: StuffIt.Tar.Archive.View
EXEFile:% ProgramFiles% \ Allume Systems \ StuffIt \ stuffit.exe -view% 1 -from_shell
ProgramID: IZArc
EXEFile:% ProgramFiles% \ IZARC \ IZARC.EXE% 1
ProgramID: WinZip
EXEFile:% ProgramFiles% \ UTILIT ~ 1 \ WINZIP \ winzip32.exe% 1
ProgramID: IZArcTZ
EXEFile:% ProgramFiles% \ IZArc \ IZArc.exe
ProgramID: WinZip
EXEFile:% ProgramFiles% \ WINZIP8 \ winzip32.exe
ProgramID: StuffIt.Tar.Archive.View
EXEFile:% ProgramFiles% \ Smith Micro \ StuffIt \ stuffit.exe -view -from_shell
ProgramID: StuffIt11.Archive.Open.Tar
EXEFile:% ProgramFiles% \ Smith Micro \ StuffIt11 \ StuffIt11.exe -o
ProgramID: TZ
EXEFile:% ProgramFiles% \ PeaZip \ PEAZIP.EXE
ProgramID: IZArcTZ
EXEFile:% ProgramFiles% \ IZArc \ IZArc.exe
сжатый файл TZ — это особый формат файла, который следует редактировать и сохранять только с помощью соответствующего программного обеспечения.
.Что означает TZ?
Touring Zone
Сообщество
000000000000000 :Туризм
0005 9005 9005 9005 9005 900 :| TZ | Танзания Региональный »Страны — и не только … | Оцените: | |||||||
| TZ | Часовой пояс Зоны | Оцените: | |||||||
| TZ | TeilZeit Международный »Немецкий | ||||||||
Twilight Zone Разное »Научная фантастика — и многое другое… | Оцените: | ||||||||
| TZ | Тренировочная зона Правительственные »Военные — и многое другое … | 9000 Оцените: | |||||||
| TZ | Test Zone Governmental »NASA — и другие … | Оцените: | |||||||
| TZ | раз Of Zambia Сообщество »Новости и СМИ | Оценить: | |||||||
| TZ | Toledo Zoo Сообщество | : | |||||||
| TZ | Transmission Zero Academic & Science »Электроника 9000 5 | Оцените: | |||||||
| TZ | TrennZahl Международный »Немецкий | ||||||||
| Оцените это: | |||||||||
| TZ | Tax Zombie Правительство »Правительство США | it : | |||||||
| TZ | Сжатый файловый архив.tar.Z (Tar and Compress) Вычислительные машины »Расширения файлов | Оцените: | |||||||
| TZ | Travel Zoom Сообщество» Путешествия и туризм | Оцените: | |||||||
| TZ | Tough Zhitt Разное »Funnies | ||||||||
| Zagato Разное »Несекретное | Оцените: | ||||||||
| TZ | Тарзан Зербини Разное» 9000 9005 4 Разное »Несекретное | ||||||||
| TZ | Транс ition Зона Разное »Несекретное | Оценить: | |||||||
| TZ | Доверенная зона Разное» Не классифицировано 4 | ||||||||
| TZ | Путешественники Zoom Разное »Несекретный | Оценить: | |||||||
| TZ | Оценить: | ||||||||
| TZ | Через ноль Разное »Без классификации | Transformatio n Зона Разное »Несекретное | Оцените его: | ||||||
| TZ | Зона обработки Разное» | ||||||||
| TZ | Зона поездки Разное »Несекретный | Оценить: |
python — есть ли список часовых поясов Pytz?
Переполнение стека- Около
- Товары
- Для команд
- Переполнение стека Общественные вопросы и ответы
- Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
- работы Программирование и связанные с ним технические возможности карьерного роста
- Талант Нанимайте технических специалистов и создавайте свой бренд работодателя
- реклама Обратитесь к разработчикам и технологам со всего мира
- О компании