Рубрика «техническое задание» - 3

Ситуация

  • На входе в студию клиент (виртуально / реально не важно).
  • Клиент хочет что-то заказать у нас — систему, сайт, приложение, аппу, что угодно — все что можно разработать и даже потом скрестить бульдога с муровьедом например (1С битрикс, просто 1С, другие системы и наша разработка).
  • Высылает он нам нечто (как мы это видим), называя это «тз» (как он это видит) и говорит — оценить / посчитать / задать вопросы и далее везде, ожидая в ответ как правило получить вполне конкретную точную цифру и срок (беру пример крайней клиники) когда это будет готово.
  • Ждет.

За годы работы я пришел к работающей конструкции в данной части воронки моих продаж — я всегда отвечаю на такие письма — отлично, получил, я вижу ваши пожелания к решениям в письме и, а тз вы забыли приложить?

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

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

Хотим рассказать о нашем первым опыте по разработки игр на Unity 3D. Надо было создать игры на национальную тематику для социального сайта El.kz. Мы давно хотели создавать игры и были рады этой новости и хотелось попробовать чего то нового. Мы предвкушали победу, потому что игры были не такими сложными, а хоть какой-то опыт по созданию игр мы имели. 4 мини игр нужно было сделать за три месяца, по нашим расчетам мы справились бы за два. Но как часто бывает корабль под названием «Ожидание» сталкивается с айсбергом «Реальность» и идёт ко дну, так случилось и с нами. Заказчик сказал, что хочет игры на flash, но как мы ему не объясняли, что технологией этой мало кто сейчас пользуется, и постепенно от неё отказываются. Но его это не волновало, а если даже волновало, то он ничего сделать не мог, так как заказ государственный и в приказе составленном год назад было написано flash игры. Выбора у нас не было, либо мы создаём игры, либо они ищут других разработчиков, но желание создавать игры и заработать нас пересилило и мы взялись за работу.
Читать полностью »

Введение

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

Примечание. Мы понимаем что есть еще стандарты на ТЗ от IEEE, ISO и пр. Однако с чего-то же нужно начинать ;-) Мы в Аксиан) придерживаемся свободных взглядов на ТЗ — главное использовать в нем общий с Заказчиком язык.Читать полностью »

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

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

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

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

В далеком 99-ом году, когда у меня появился первый самостоятельный заказ на разработку веб-системы (3-ий курс) мне необходима была опора, которая позволила бы достойно выглядеть перед заказчиком без риска уйти в переработки за свой счет. Мой отец – крутой специалист в области проектирования АСУТП, всегда говорил мне – пиши ТЗ. Читать полностью »

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

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

Как создать концепцию продукта и написать ТЗ на разработку электроники

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

image

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

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

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

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

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

Разгребал «ящики» и обнаружил один очень интересный проект! Называется он SpecsMe, а направлен на решение одной из самых насущных проблем ИТ-агентств. Цель проекта: автоматизация составления ТЗ и создание инструментов для дальнейшей работы (удаленные доступы, одновременное редактирование, биржа и тд). Отдам в хорошие руки. Подробности под катом.

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js