Розробка · 16 жовтня 2015, 12:48 1585

Igor Rudnyk, Internet marketing, branding

Стандарты программирования

Добрый день.

Я не программист, а заказчик. Есть вопрос по трактовке ТЗ.

Суть проекта — личные кабинеты для собственного использования. Работа была отдана одной команде на аутсерс. Мы предоставили программистам подробное ТЗ в виде макетов в акшуре и подробного ТЗ на 170 страниц.

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

На сколько мне пояснили знакомые разработчики, есть международные стандарты, в которых это описано. И такие вещи нет нужды описывать в ТЗ, т.к. это само собой понятно, что функция должна быть обратимой. Так ли это?

Спасибо.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Теми: стандарти, ТЗ

👍ПодобаєтьсяСподобалось0

До обраногоВ обраному0

Facebook

Twitter

LinkedIn

Ctrl + Enter

Ctrl + Enter

Антон Коба Software Engineer 17.10.2015 23:59

“When you ASSUME you make ASS of U and ME”

Відповісти

Підтримати

Молдавский Узбек 17.10.2015 17:52

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

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

Плюс, все то, что подразумевается, не всегда воплощается. Кроме здравого смысла, ничего не мешает сделать возможность создавать и удалять в системе новые сущности, но не создать возможность их редактирования. А не просили же....

Даже сверхподробное ТЗ не гарантирует защиты от этого перекоса, если не было возможности совместно с исполнителем проговорить требования, шаг за шагом, с быстрой фиксацией разночтений и итоговых договоренностей. Шелдон Купер с его полиси о совместном проживании гарантирует это 31.media.tumblr.com/...obd3dRWY1qftmvzo1_400.gif

Відповісти

Підтримати

Микола Федчик Project Manager в Infineon 17.10.2015 14:38

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

Відповісти

Підтримати

Igor Rogov 17.10.2015 13:22

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

Відповісти

Підтримати

Gennady Dogaev full-stack web developer (freelance) 17.10.2015 13:17

На сколько мне пояснили знакомые разработчики, есть международные стандарты, в которых это описано. И такие вещи нет нужды описывать в ТЗ, т.к. это само собой понятно, что функция должна быть обратимой. Так ли это?

Нет. Описывать нужно каждую кнопку в интерфейсе и как она должна работать. Всё что не описано будет делаться или не делаться на усмотрение и совесть исполнителя.
Некоторые например считают, что если есть форма добавления сущности (например, ссылки в профиле пользователя) и дизайнер забыл нарисовать кнопку удаления — значит не нужно удаления и об этом даже уточнять не будут. А на замечания отвечают «а в ТЗ этого не было».
И формально такой исполнитель будет прав, хотя я считаю что так делать нельзя, так как продукт делается для людей, для которых непродуманная фича может оказаться бесполезной. Но и заказчик должен идти навстречу. Если Вы о чём-то забыли в ТЗ — будьте добры предложить внести необходимую доплату вместе с необходимыми исправлениями.

Відповісти

Підтримати

Igor Rudnyk Internet marketing, branding 17.10.2015 13:30

Окей, спасибо.

Відповісти

Підтримати

Серега Коваленко 17.10.2015 13:05

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

Відповісти

Підтримати

Gennady Dogaev full-stack web developer (freelance) 17.10.2015 13:19

а ты не думал, что эти 170 страниц никто не читал?

Должны читать, как и договора. Иначе это рас*****и, а не исполнители.

Відповісти

Підтримати

Серега Коваленко

Igor Rudnyk Internet marketing, branding 17.10.2015 13:30

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

Відповісти

Підтримати

Серега Коваленко

Vladimir Pauchev Don't care 17.10.2015 19:09

Давайте аналогию. Вы приходите в салон и заказываете себе BMW. Все обсудили, комплектацию, цвет салона, диски. Подписали договор. Через два месяца будет. И тут звонит вам менеджер салона и говорит, «а мы тут подумали, может ты на рыбалку ездить будешь, и вместо BMW поставим вам Ниву. Зеленую. 5 летнюю. Все же на рыбалку ездят, мужики подтвердят».
Де факт стандарт такой, при fixed price разработке все что забыли или не так в ТЗ оплачивается сверху.

Відповісти

Підтримати

Олексій Пєніє 17.10.2015 03:31

Само собой ничего в этом мире не понятно, это тебе любая дама в сине-чёрном платье скажет. Если у тебя ТЗ на 170 страниц, то только за его чтение уже приходится оплачивать время деньгами. И чем оно непонятнее, тем дороже.

Понятия «обратимой функции» не существует как такового. Вводи его сам в ТЗ, отдельно поясняй, и давай гиперссылку на это определение каждый раз где могут быть сомнения.

Требование «все функции обратимы» равносильны утверждению «я дурак, но не говорите мне этого». Либо вы ЗНАЕТЕ как работает конкретное действие в деталях, и хотите дать конкретные указания — это директива. Либо НЕ ЗНАЕТЕ, и тогда описываете исключительно своим словарным запасом, как понимаете сами, и даёте разъяснение [как правило если спросят] — это юзер кейз. Если вы пытаетесь объяснить то, чего не знаете сами, с помощью слов которых не знаете — вы гарантированно приходите к ситуации когда этот язык не понимает никто из вас, и каждый думает что другой понимает, чё сказал.

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

Чаще всего, практически всегда, применяется сохранение. Но строго определённого кусочка данных, на который оказывается влияние.

Например — как в текстовом редакторе вы можете вернуть что было? Очень просто. В памяти сохраняется ЦЕЛИКОМ весь абзац, и когда вы нажмёте кнопку вернуть — его вернут. То есть никакой обратной функции нет, есть просто копия. И чем больше операций вы делаете, чем больше данных затрагиваете — тем больше памяти требуется, и тем меньше операций можете вернуть. Так вот, текст — это небольшие по объёму данные. Вам же наверняка приходится иметь дело с огромными. Заметьте, после нажатия на кнопку «сохранить», ничего вернуть вы уже не можете. Это почему ВСЕ функции не могут быть обратимыми — потому что обратимости нет. Есть ОДНО место, куда можно положить данные. Если вы хотите иметь возможность вернуть — вам придётся иметь ДВА таких места, три, четыре, сколько потребуется.

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

PS. Избегайте слов «все», «каждый» в юридических текстах. Здесь строгая логика. Точно указывайте критерии. В лучшем случае у исполнителя есть юрист, который перечитает и потребует конкретики. В случае «как всегда» — вы разойдётесь врагами, с чёрной репутацией, с неработающим софтом и впустую потраченными деньгами и временем. И стоило писать задание на 170 листов, чтобы его провалить? Когда можно юзер-кейз на 30 страниц, который будет делать чего хотел пользователь.

PPS. А вы говорите «само собой понятно».

Відповісти

Підтримати

Igor Rudnyk Internet marketing, branding 17.10.2015 13:32

Понял. Спасибо за развернутый ответ

Відповісти

Підтримати

Олексій Пєніє

Pavlo Suikov меня интересуют только мыши, их стоимость, и где приобрести в GlobalLogic 17.10.2015 00:55

есть международные стандарты, в которых это описано

такие вещи нет нужды описывать в ТЗ

В таком случае в ТЗ должна быть ссылка на эти стандарты с явным указанием требования соответствия.

Відповісти

Підтримати

Igor Rudnyk Internet marketing, branding 17.10.2015 13:33

Понял, ок. В следующий раз уделю больше внимания

Відповісти

Підтримати

Byte Surfer 17.10.2015 00:45

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

Відповісти

Підтримати

Igor Rudnyk Internet marketing, branding 17.10.2015 13:34

«Косяк» ни на кого не перекладывался. Я лишь уточнил у сообщества, есть ли общепринятые стандарты, либо же все ограничивается только написанным ТЗ.

Відповісти

Підтримати

Mobile 17.10.2015 00:41

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

Відповісти

Підтримати

Олексій Пєніє 17.10.2015 03:39

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

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

Відповісти

Підтримати

anonymous 16.10.2015 22:31

Легче сделать работу, чем описывать ее на 170 страницах.

Відповісти

Підтримати

Igor Rudnyk Internet marketing, branding 17.10.2015 13:36

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

Відповісти

Підтримати

Vadim Kopanev Architect 16.10.2015 18:01

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

Відповісти

Підтримати

Igor Rudnyk Internet marketing, branding 17.10.2015 13:36

Спасибо, Вадим.

Відповісти

Підтримати

Mikhail Boiko SE в NVIDIA 16.10.2015 13:00

Представьте что вы заказали дом. Пришли к строителям и сказали хочу дом, размером 5 на 5 метров, высотой 3 метра, из кирпича, хочу чтоб стоял здесь. Вам сделали этот дом, а вы пришли и удивились — в нем нету окон. А у вас есть знакомый, он где-то слышал про какой-то СНиП в котором сказано что в помещение должен попадать солнечный свет.

Кто виноват в этой ситуации?

Відповісти

Підтримати

Igor Rudnyk Internet marketing, branding 16.10.2015 13:02

ок, спасибо. Весьма доходчиво)

Відповісти

Підтримати

Arthur Belov Mobile TechLead 16.10.2015 22:28

Вообще-то застройщик виноват в данном случае, так как обязанность по утверждению всей строительной документации, в том числе на соответствие СНиПов, чаще всего лежит на нём. Однако идея правильная — написали ТЗ на 170 страниц — будьте готовы что всё будет выполнено в точности с таким ТЗ. Хотя сами разработчики могли и догадаться спросить у заказчика про необходимость обратимости функций.

Відповісти

Підтримати

Олексій Пєніє 17.10.2015 03:41

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

Відповісти

Підтримати

anonymous 16.10.2015 22:34

Если ТЗ подавалось в 170с с макетами, то или ТЗ хувое или програмеры ху%вые.

Відповісти

Підтримати

Oleksandr Holovko SDE в ЗСУ 17.10.2015 14:33

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

знавал компании где лично сам руководитель утверждал макеты дизайна и только после того как все с его точки зрения было ок, макет утверждался с заказчиком. Такой подход обычно был достаточно дорогим для клиента, но и результат соответствовал. Как минимум ТЗ должно было пройти через обсуждения и UX анализ, в которых должны были выявится некоторые упущения, поэтому вина пожалуй будет разделена:
Клиент виноват потому что воспользовался недостаточно квалифицированной помощью, не имел собственного консультанта\опыта, и пропустил важные моменты
Исполнитель с юридической точки зрения прав, но по человечески (и с точки зрения репутации) не решил проблему заказчика, а просто механически закрыл заказ.

Как решать проблему? — Компромиссом

Відповісти

Підтримати

Gennady Dogaev full-stack web developer (freelance) 17.10.2015 15:07

если исполнитель делает в тупую даже не задаваясь вопросом, а так ли все надо делать? то имхо — это не очень хороший исполнитель

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

Відповісти

Підтримати

Oleksandr Holovko

Микола Федчик Project Manager в Infineon 17.10.2015 20:32

Но есть же общепринятые стандарты

Молодой человек, а давайте вы не будете разбрасываться терминами по Интернету...
Или же назовите конкретные из перечисленных, в частсности международные (ISO) или отраслевые (IEEE, ДСТУ)
А то я тоже «знавал» разные компании... :)

Відповісти

Підтримати

Oleksandr Holovko

Підписатись на коментарі

Ваша пошта

Не підписуватись