Как-то раз Машенька пошла в лес по грибы да по ягоды, а вернулась ни с чем… Потому что цели и задачи нужно формулировать более конкретно.

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

Общий план составления технических требований

Терминология:
  • Техническое задание, ТЗ – основной документ, описывающий конструкцию, принцип работы и назначение создаваемого технического объекта. ТЗ создаётся специалистом на основании требований, предъявляемых задачедателем, с учётом возможностей современной техники, физических ограничений, имеющихся примеров решения схожих задач, экономической целесообразности.
  • Технические требования, ТТ – изложенное задачедателем(заказчиком) в письменной или любой другой форме описание того, что он в итоге хочет получить.
 
Список вопросов, ответы на которые должны содержаться в технических требованиях:
  • Для чего нужно устройство, кто где и как будет им пользоваться? Лучше всего изложить специалисту задачу, как она есть, а уже специалист предложит наилучшее решение.
  • Есть ли на рынке готовые аналоги, какие они имеют недостатки?
  • Устройство предназначено для технологического использования, или для конечного пользователя?
  • Есть ли у устройства корпус ? Важен ли дизайн, требования к дизайну, герметичность, ударопрочность, материал.
  • Откуда устройство получает питание, от электросети, от аккумулятора, от батарейки, как-то ещё? Каким образом происходит зарядка аккумулятора, замена батарейки?
  • Какие у устройства есть органы управления, ручки, кнопки, джамперы, программа-интерфейс на ПК, удалённый WEB-сервер ?

Гайка М3 и ТЗ на разработку

Автор: Иосиф Григорьевич Каршенбойм
http://www.iosifk.narod.ru
iosifk@narod.ru

 

В телеконференции я часто вижу такие вопросы: «помогите, я не знаю, как ….» и далее следует что-либо маловразумительное, ну например «есть три микроконтроллера, а я не знаю, как передавать данные из двух в третий». Потом на этот пост идут ответы о том, как работают порты UART или SPI. Но практически никто не задает вопроса о том, какая предполагается архитектура сети, какая география, какой протокол обслуживания, кто будет мастером, будет ли передача эстафеты и т.д., а главное, для чего это нужно, что за задачу будет выполнять вся эта конструкция. Поэтому все ответы по-своему правильные, но они не достигают цели, потому, что неправильно был сформулирован вопрос.

Или вот реальный пример, вопрос о том, какой стартовый набор применить для изучения: «Все когда-то начинали изучать Ethernet. Хотелось бы узнать, кто каким китом пользовался. Порекомендуйте марку кита, его возможности, что является "мозгом" (МК, DSP, CPLD, FPGA)? Ну и его цену (по возможности)». На ответ о том, что не бывает «просто Ethernet», так же как не бывает «просто автомобиль», автор поста заявляет, что просто хочет научиться ... «все равно на чем».

Что можно сказать об этих вопросах? А сказать можно только одно. Те, кто их задавал, не умеют правильно сформулировать свои вопросы. И что удивительно, этому до сих пор не учат в институтах. Изменились многие курсы, но вот такой науке, науке формулирования задания на разработку – похоже не учат нигде. Вот что я написал в одной из моих статей: «Известный герой детских сказок любил сначала закапывать деньги, а потом долго не мог вспомнить, что он делал накануне вечером и куда делись деньги. Чтобы у нас с вами такого не произошло, попробуем сначала «нарисовать известное поле». На старом языке этот этап назывался разработкой технического задания».

 
Вот теперь давайте обсудим, что такое разработка, что такое ТЗ и причем тут «поле дураков».

Для многих, даже можно смело сказать для большинства тех, с кем приходилось общаться, понятие «разработка» сводится к микроконтроллеру, операционной системе, слоям в печатной плате, припою, микросхемам и программным инструментам. Но на самом деле это не совсем так. Когда люди вступают в трудовые взаимоотношения, то они должны договориться о том, что надо сделать и за какое вознаграждение. Вот поэтому, разработка – это, прежде всего, грамотно составленное ТЗ, которое должно быть выполнено. По крайней мере, автора этих строк учили именно так. А микроконтроллер, операционная система и все остальное – это только СРЕДСТВО для выполнения ТЗ. Наверное, должно быть всем известно, что если то устройство, что Вы сделали, не выполняет хотя бы один из пунктов ТЗ, то работа считается НЕ ВЫПОЛНЕННОЙ. Поэтому при составлении ТЗ необходимо учесть все факторы, которые могут встретиться при разработке. И тут должно быть такое правило – если сомневаешься, что сможешь выполнить этот пункт ТЗ, то лучше его не вносить в ТЗ, такой пункт можно будет потом ввести в ТЗ, как приложение, как дополнение, или как новую версию ТЗ.

Теперь пара слов о том, как надо и как не надо составлять ТЗ. Здесь есть два способа. Один я называю «от гайки М3», второй «от алгоритма».

Вот способ составления ТЗ - «от гайки М3»:

«У меня есть гайка М3, этой гайкой я могу прикрутить железную ручку к модулю. А модуль – это такой кусок пластмассы, на который «влезут» 10-20 микросхем. А эти 10-20 микросхем смогут … и еще при этом смогут … и .. а дальше видно будет, что получится».

Второй способ - «от алгоритма»:

«У меня есть алгоритм, описанный в ТЗ. Чтобы реализовать этот алгоритм, мне необходимо иметь обработать ХХ-данных за квант времени, для этого мне надо иметь YY-памяти, ZZ-разрядность шин и SS-вычислительную мощность. Такую блок-схему вычислений я могу так-то и так-то разделить между soft-вычислителем и hard-вычислителем. Для этого мне нужны такие-то процессоры и такие-то ПЛИСы. И для их размещения будет достаточно такой-то PCB со столькими-то слоями. …(дальше я пропускаю, потому что все дело должно закончиться словами..)…гайка М3».

В чем же разница? Все равно и там и тут есть «гайка М3». А разница в том, что в первом варианте гайка точно будет привинчена «насмерть». А вот будут ли выполняться все алгоритмы, о которых говорится в ТЗ? Как показывает практика, для первого варианта всегда что-то забывается и не учитывается. И это обнаруживается только потом, когда прибор уже сделан, и все переделки и исправления достаточно дороги или вообще невозможны.

В качестве примера могу рассказать о том, что я видел сам. Когда делали систему управления, о которой я рассказывал в «Записках Инженера», то выяснилась такая «маленькая деталь». Система была распределена по объекту и охватывала объект управления в радиусе 12 км. И когда первую систему сделали, поставили на объект и дело дошло до приемо-сдаточных испытаний, то неожиданно выяснилось, что для того, чтобы система заработала, надо сделать «ВКЛ.» Причем это «ВКЛ» надо было сделать в сотне аппаратных. А в суете и спешке об этом не подумали. Да и заказчик об этом не сказал. Вот и пришлось в спешном порядке создавать сначала группу, а потом и целый сектор, который разработал специальную стойку, которая дистанционно делала «ВКЛ». Потом эти стойки, по штуке на аппаратную, надо было так-же бодро смонтировать в эти самые сотни аппаратных, связать кабелями управления. А кабельные вводы в сооружения – это герметезированные сальники и их пришлось вскрывать. А самое главное – пришлось в ТЗ вводить специальную главу о «ВКЛ», срочно делать комплект конструкторской документации (КД), проводить его через ПЗ и утверждать у заказчика. А КД - это КД на стойку, на кабели, на кроссовые ящики, на кроссовые шкафы, на системы. Вот что значит «немного не учли в ТЗ»…

Чтобы себя обезопасить от таких «проколов» попробуйте «нарисовать поле дураков». Возьмите лист бумаги и напишите в левый столбик – «функции, которые должны выполняться». Как когда-то меня учили программисты: «перестань нам рассказывать, какие у тебя там микросхемы, ты скажи, что они делают и в каком порядке». А в правой колонке – какие средства эти функции выполняют. Итак, первично - это алгоритм, описанный в ТЗ. Вот в таком варианте алгоритмы должны выполняться. А что касается «гайки М3», то возможно в результате разработки конструктив может быть выбран другой и, соответственно, гайка может иметь другие размеры, например дюймовые.

И теперь снова о телеконференциях. Когда Вы задаете вопрос коллегам, это значит, что Вы их спрашиваете о том, как для Вас решить некую задачу. То есть Вы для них формулируете ТЗ. Поэтому постарайтесь сформулировать задачу ГРАМОТНО И ПОЛНО.

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

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

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

Вот и все, что хотелось сказать по этому поводу. Удачи!