Рубрика «тз» - 3

в 7:55, , рубрики: Блог компании КРОК, боль, ит-инфраструктура, мы уважаем благородных утконосов, техзадание, тз

Не наступайте на наши грабли с ТЗ: эпический опыт конкурсов и пара баек - 1
Широко известный пример неточно поставленного ТЗ

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

Было сложно — не то слово. В длинном перелёте я читал ТЗ на 20 страниц. В нём была такая особенность: если читать его бегло, то может показаться, что оно написано правильно и точно. Но если начать копать в детали инженерной реализации, то всплывало сразу много нежданчиков. Некоторые требования подпунктов, вроде 3.2.5 и 4.8.2.9, могли противоречить друг другу или быть просто взаимно невыполнимыми в реальном мире.

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

в 10:00, , рубрики: CRM система, CRM-системы, ERP-системы, Блог компании RegionSoft Developer Studio, техническое задание, тз, тз на crm, тз на программирование, управление проектами, управление разработкой

Если пройтись по зарубежным сайтам с запросом «product requirements document», то можно найти креативные и убедительные статьи про то, что техническое задание (ТЗ, PRD) умерло. Отчасти с этим нужно согласиться — при разработке продукта с нуля прототипирование выглядит гораздо интереснее и эффективнее, чем тома записей заказчика, порой ну очень непрофессиональные. Однако, если речь идёт о доработке базовой системы, то дело принимает совершенно другой оборот. Мы сталкиваемся и с доработкой, и с заказной разработкой, поэтому на ТЗ собаку съели, если повар нам не врёт. В общем, сегодня — о тех самых классических технических заданиях, которые пишутся на доработку купленного и установленного программного обеспечения. Короче, о наболевшем.

Техническое задание на доработку: 10 правил и немного занудства - 1

Читать полностью »

в 8:18, , рубрики: прототипирование, Развитие стартапа, тз

Эта статья в первую очередь пригодится тем, кто пишет ТЗ для программистов, и программистам, которые решили разрабатывать прототип самостоятельно.

Многие относятся к созданию визуального прототипа, написанию ТЗ, как к некоему творческому, порой спонтанному процессу. И во многом они правы. В этой статье приводятся полезные для практики правила (о большинстве из которых мы знаем, но часто забываем воспользоваться), принятие которых поможет повысить качество результата и снизить временные затраты.Читать полностью »

в 13:20, , рубрики: Анализ и проектирование систем, документация, Проектирование и рефакторинг, разработка, тз, управление проектами

Вы пишите лишнюю документацию для вашего проекта? Нет? Тогда вам ее недостаточно!

Угадать для каждого конкретного проекта необходимый объем технической документации крайне сложно и важно. Важно — потому, что от этого зависит скорость процесса, качество и стоимость. Сложно — потому что сам процесс может меняться со временем, могут меняться исполнители, да и для заданного состояния процесса не так просто подобрать нужный набор и объем документации.

Здесь хотел бы рассказать о своем подходе к документированию работ по небольшим проектам. Небольшой проект это: руководитель-аналитик, 1-3 разработчика, тестеровщик или что-то подобное. Под документацией я понимаю какие-либо артефакты, создаваемые для поддержки следующих процессов: обсуждения, управление требованиями, управление изменениями, управление версиями. Другие процессы я не документирую.
Читать полностью »

в 9:25, , рубрики: Внедрение, договор, документооборот, продажа, сэд, техническое задание, тз, управление проектами

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

Знакомство заказчика с системой

Редко какая система документооборота бывает простой в плане изучения. Но тот, кому это нужно, конечно, разбирается, изучает, зачастую с нашей помощью. В ход идет все — ICQ, Skype, форум, телефонные беседы.

У нас на сайте имеется бесплатная версия на 5 пользователей, можно изучать неограниченно. Также есть триальная лицензия на полгода на 50 (или более) пользователей. Заказчик изучает, сразу строит свои бизнес-процессы, проектирует типы документов, заводит пользователей и подразделения. Все это время он спокойно живет и пользуется, без заключения договора и без затрат со своей стороны. Не понравится — бросит и уйдет. Триальную лицензию по согласованию с нами он может продлить на сколько угодно, пока мы не признаем в нем «читера».
Читать полностью »

в 19:18, , рубрики: проектирование, Проектирование и рефакторинг, процесс разработки, разработка, техническое задание, тз, метки: , , ,

«Идеального технического задания не существует».

Не раз слышал фразы подобного рода, в ситуациях когда разработчики реализовали не «то» и не «там», при это ссылаясь на отсутствие идеального технического задания от заказчика, аргументируя: «если бы это было указано в ТЗ, тогда бы ..».
Читать полностью »

в 10:36, , рубрики: бизнес студии, бриф, веб-дизайн, Веб-разработка, ведение проекта, тз, метки: , ,

Недавно мы собирали материалы в рамках ситуационного анализа. В первую очередь нас интересовали компании из рейтингов, брендинговые агентства и питерский рынок. Задача анализа простая – составить общее впечатление работы рынка, оценить уровень сервиса и ценообразование. Неожиданно для себя, мы нащупали еще одно слабое звено, им оказался бриф. Притом это странно, казалось бы, уже трактаты написаны об этом вопроснике, но нет, до сих пор люди спотыкаются, считают это мелочью, не обращают внимание. И не только молодые компании. Такое встречается в 40%. Но умение задавать правильные вопросы и не задавать глупые является лакмусовой бумажкой, вот так с порога многие компании признаются в некомпетентности.
Читать полностью »

в 14:53, , рубрики: seo, Веб-разработка, маркетинг, тз, управление проектами, метки: , ,

Идеальный сайт – ТЗ как основа работы сайта, построенного на базе грамотных программных решений

Представьте себе, что Вы как владелец некой компании заказываете сайт компании у студии разработчика. Ситуация вполне стандартная и развивающаяся по стандартному сценарию.Читать полностью »

в 8:24, , рубрики: Анализ и проектирование систем, взаимодействие с заказчиком, заказная разработка, оценка стоимости проекта, тз, управление проектами, фриланс, метки: , , , ,

При таком сочетании – быстро, точно, без ТЗ – кажется, что задача не имеет решения. Однако в работе фрилансера такие задачи возникают постоянно, поэтому в борьбе за выживание заказы приходится учиться их решать. Для начала поясню, что означают вынесенные в заголовок слова.

Быстро – значит, раньше, чем заказчик примет решение о выборе исполнителя (другого исполнителя, раз вы еще не готовы ответить ему на самый главный вопрос).
Точно – значит, достаточно близко к реальной стоимости проекта, которую можно было бы озвучить после согласования ТЗ (а еще лучше после выполнения проекта, когда уже известно точное количество потраченного на разработку времени).
Ну и, наконец, что значит Без ТЗ? Понятно, что проектов совсем без ТЗ (в стиле «пойди туда, не знаю куда, принеси то, не знаю что») практически не бывает. Другое дело, в каком виде заказчик предоставляет вам это самое ТЗ.
Читать полностью »

в 22:43, , рубрики: Айзек Азимов, заказчик, Программирование, разработка, техническое задание, тз, философия, фриланс, метки: , , , , , , ,

Думаю, многие слышали о законах роботехники, сформулированных Айзеком Азимовым:

  1. Робот не может причинить вред человеку или своим бездействием допустить, чтобы человеку был причинён вред.
  2. Робот должен повиноваться всем приказам, которые даёт человек, кроме тех случаев, когда эти приказы противоречат Первому Закону.
  3. Робот должен заботиться о своей безопасности в той мере, в которой это не противоречит Первому и Второму Законам.

Эти законы являются высокоуровневой моделью поведения каждого «правильного» (по версии Азимова) робота, но на этом их призвание не ограничивается.

В статье я чуть подробнее раскрою смысл этих законов, покажу, как они могут быть применены к сферам, отличным от робототехники, и попытаюсь выработать три закона разработки. Статья не несет прямой практической пользы, я это понимаю, поэтому заранее советую залезать под кат только тем, кому не жалко потрать несколько минут на мои рассуждения и обсудить их со мной в комментариях.
Читать полностью »

1...234
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js