[DeadCadDance 0]

1 час назад, a123-flex сказал:

Реальное решение проблемы - убрать вас из этой задачи)

А я то здесь причём? Я и так не участвую в решении задачи. Задачу решает исполнитель.

1 час назад, a123-flex сказал:

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

Я тоже так начальству говорил: "Дайте людям МИНИМУМ 3 года".

Но меня и слушать никто не захотел из высшего руководства. Говорят "9 месяцев, максимум год! И не более!"

1 час назад, a123-flex сказал:

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

"Для любой, даже самой сложной, задачи всегда можно быстро найти простое и НЕ ПРАВИЛЬНОЕ решение"(с)

Да?

15 минут назад, Raven сказал:

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

Вы так спрашиваете, как будто в России это что-то из ряда вон выходящее, когда исполнитель хватается за ЛЮБУЮ работу, как утопающий за соломинку, а потом понимает, что она ему не по силам. Серого вещества в мозгу не хватает. А договор уже заключён.

 

17 минут назад, Raven сказал:

Деньги тоже выплатили? Или только время пока потеряли? А то этот момент тоже неясен.

По текущему проекту пока не все выплатили.

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

 

И общаясь с коллегами с других предприятий, я так понимаю, что данная ситуация в России ПОВСЕМЕСТНО.

Платку спроектировать нормально и даже "коробочку" ещё можно.

А если что-то более сложное - то такие проекта почти всегда в России заканчиваются фак апом

[syoma 1]

3 hours ago, DeadCadDance said:

Сразу набежало куча народу, согласные реализовать ВСЕ наши хотелки в указанные сроки и за указанные бапки. Мы (как нам казалось) выбрали лучшего исполнителя. А в результате получили хлам, который можно только выкрасить и выбросить. Хотя сроки несколько раз переносились и мы переплатили как минимум ВТРОЕ

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

Т.е. грубо говоря, вы просили сделать вам автомобиль с квадратными колесами. Это абсолютно понятное требование и даже я под него подпишусь и реализую. Но если такой автомобиль не едет - это ваша проблема.  

[DeadCadDance 0]

16 минут назад, syoma сказал:

исполнитель все их выполнил

Исполнитель не выполнил БОЛЬШИНСТВО требований.

И требовал их отменить ( изменить ТЗ) по причине, что для него это слишком сложно

Изменено 6 июля, 2020 пользователем DeadCadDance

[nbn 1]

4 минуты назад, DeadCadDance сказал:

Исполнитель не выполнил БОЛЬШИНСТВО требований.

И требовал их отменить ( изменить ТЗ) по причине, что для него это слишком сложно

Автор пишет фантастический рассказ?

[AlexandrY 2]

3 minutes ago, DeadCadDance said:

Исполнитель не выполнил БОЛЬШИНСТВО требований.

И требовал их отменить ( изменить ТЗ) по причине, что для него это слишком сложно

Так это ж нормально. По идее это вы должны изменить требования видя сложности. 
Требованиями в проектах управляют, а не их выставляют. 
 

[syoma 1]

7 minutes ago, DeadCadDance said:

Исполнитель не выполнил БОЛЬШИНСТВО требований.

И требовал их отменить ( изменить ТЗ) по причине, что для него это слишком сложно

 

Just now, AlexandrY said:

Требованиями в проектах управляют, а не их выставляют. 

Не только требованиями, но и рисками. Если требование было сложным, дорогим в исполнении или вы не были уверены в том, что исполнитель его правильно понял и имеет нужную компетенцию, вы обязаны были сделать derisking - то есть уменьшить свои риски удорожания или срыва проекта из-за невыполнения этого требования. 

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

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

[a123-flex 0]

19 минут назад, syoma сказал:

 

Не только требованиями, но и рисками. Если требование было сложным, дорогим в исполнении или вы не были уверены в том, что исполнитель его правильно понял и имеет нужную компетенцию, вы обязаны были сделать derisking - то есть уменьшить свои риски удорожания или срыва проекта из-за невыполнения этого требования. 

Я думаю, что они просто ничего не понимают в той задаче, которую отжали. ТЗ это набор округлых фраз, обыгрывающих ТЗ министерства, и вся эта группа паразитов скорее всего тупо пялится в печалях в график потерь и просрочек))

 

Цитата

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

вот я думаю точно они ничего не делали)

 

Цитата

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

этож денег стоит))

 

Кроме того, цитата ниже - они даже неспособны оперативный контроль организовать, исполнения пунктов плана. Да и плана видимо никакого нет))

 

1 час назад, DeadCadDance сказал:

А я то здесь причём? Я и так не участвую в решении задачи. Задачу решает исполнитель.

Я тоже так начальству говорил: "Дайте людям МИНИМУМ 3 года".

нет никакого плана)

 

Цитата

Но меня и слушать никто не захотел из высшего руководства. Говорят "9 месяцев, максимум год! И не более!"

Смысл простой. Тк вы сами как ничего не знали о задаче, так и не знаете, а исполнитель ДОЛЖЕН понемногу чемуто учиться, в итоге вы выпадете из цепочки, как ненужный паразит. 

 

Если правда и исполнитель ничему не учится... Тогда ой. Присядут тогда рядом 2 группы представителей - от исполнителя и от вас))

[rudy_b 1]

18 hours ago, DeadCadDance said:

Я тоже так начальству говорил: "Дайте людям МИНИМУМ 3 года".

Но меня и слушать никто не захотел из высшего руководства. Говорят "9 месяцев, максимум год! И не более!"

И кто после этого дурак?

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

Полностью согласен с syoma.

 

[Михась 2]

Тут уже была аналогичная тема, созданная каким-то Моисеем Соломоновичем про АСУТП с микросекундным циклом. Похоже это развитие офигенной истории.

[HardEgor 63]

18 часов назад, DeadCadDance сказал:

Я тоже так начальству говорил: "Дайте людям МИНИМУМ 3 года".

Но меня и слушать никто не захотел из высшего руководства. Говорят "9 месяцев, максимум год! И не более!"

Аа-а-а, так это известная тема, вас просто "берут на понт" - обычно так молодых напрягают, - "ты, говорят ищи, я точно знаю что такие темы так быстро делаются". И вот "молодой и горячий" начинает гуглить "серьезные фирмы", писать в соответствующие темы в соцсетях, заваливать форумы вопросами, а на все отрицательные ответы писать - "да вы нифига не понимаете, буду ждать реальных разработчиков"....

[Михась 2]

Народ,  успокойтесь. Вот нормальное чтиво. Вениамин Иосифович видимо опять развлекается.

http://iprog.pp.ru/forum/read.php?f=1&i=74671&t=74671&v=f

 

Он на многих асутпшных форумах холку чешет

https://asutpforum.ru/viewtopic.php?f=12&t=7318&sid=a174ff557ce321d218306b5c42efa309

Изменено 7 июля, 2020 пользователем Михась

[DeadCadDance 0]

51 минуту назад, rudy_b сказал:

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

ТЗ пишут не "эффективные менеджеры". Потому что "не барское это дело". А попросту говоря, им это западлО. Всё сваливается на нас, несчастных  рядовых инженеров (и мы всегда во всём виноваты).

Но мы, как люди простые,  отнеслись к этому делу со всей ответственностью.

Исследовали объект, беседовали каждый день на протяжении полугода с технологами на предмет: "ачо вам, собссно говоря, надо-то?"

Родили ТЗ. Объёмом где-то 150 страниц. Стараясь отразить в нём реально достижимые вещи даже для инженера "средней руки".

 

Но как выяснилось, исполнитель даже не прочитал полностью ТЗ, но при этом подписался под договором.

 

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

 

 

[nbn 1]

Ответ на главный вопрос https://insat.ru/about/publications/

[Eddy_Em 1]

42 minutes ago, nbn said:

Ответ на главный вопрос https://insat.ru/about/publications/

Когда пишешь в ТЗ, что итоговый продукт должен быть построен так, чтобы была возможна его поддержка и развитие исключительно собственными силами работников предприятия, многие подобные "инсаты" моментально сливаются! Ведь это придется давать расширенную документацию, полную расшифровку протоколов обмена данными, а зачастую — еще и исходные коды (что до меня, так я бы еще и требовал все исходные коды исключительно под лицензией GPLv3)!

Изменено 7 июля, 2020 пользователем Eddy_Em

[andrey_p 0]

1 hour ago, DeadCadDance said:

Родили ТЗ. Объёмом где-то 150 страниц. Стараясь отразить в нём реально достижимые вещи даже для инженера "средней руки".

Ниже описан процесс разработки некой системы схожего масштаба. Разработка велась западной компанией, в которой я работал.

 

Заказчик хочет сделать "чтобы было зашибись". Свои пожелания он излагает в кратком документе (1-2 страницы) "своими словами". Этот документ называется WP (White Paper) и/или VoC (Voice of the Customer).

 

Действия исполнителя (сначала потенциального исполнителя):

1. На основе WP / VoC создаётся HLSA (High Level Solution Approach). Обычно HLSA делается в виде презентации для демонстрации заказчику с целью согласования единого видения функционала. Причём техническая часть презентации создаётся группой системных инженеров / архитекторов (эта группа тесно связана с "продаванами"). В некоторых случаях проводится НИОКР.
2. По результатам обсуждения HLSA с заказчиком вырабатывается общее понимание. HLSA может итеративно дорабатываться исполнителем в ходе обсуждения.
3. На основании HLSA создаётся TRD (Technical Requirements Document). Это те самые высокоуровневые требования, под которыми подписывается заказчик и по которым делается оценка. На основании TRD заказчик будет проводить приемо-сдаточные испытания.
4. На основании TRD исполнитель создаёт SRD (System Requirements Document), включающий внутренние требования, невидимые заказчику. Это часть очень важна, так как требования в TRD являются слишком высокоуровневыми для создания системы. Количество требований в SRD может в десятки раз превышать количество требований в TRD. Делается TM (Tracability Matrix) из TRD в SRD.
5. На основании SRD делается SAD (System Architecture Document), описывающий декомпозицию и интерфейсы между компонентами. Делается TM из SRD в SAD.
6. На основе SAD для каждого компонента делаются BR (Box Requirements) и TM из SAD/SRD в BR. BR используется тестировщиками для создания документов по тестированию, а затем и самих тестов. Создаются TM до самых тестов.
7. На основе SAD для каждого компонента делаются HLD/LLD (High Level Design / Low Level Design) со сквозными ТМ. Создаются сами компоненты.
8. Низкоуровневые части компонентов тестируется разработчиками на основании HLD/LLD (Unit Testing)
9. Каждый компонент проверяется соответствующей группой тестирования на соответствие конкретному BR.
10. Вся система тестируется на соответствие SRD. Этот этап разделяется на два: системная интеграция / системное тестирование SI/ST (System Integration / System Testing)
11. Система передаётся заказчику для приемо-сдаточных испытаний (по TRD)

Писал по памяти, но, вроде, ничего не упустил:)

Ещё есть документы финансовые, по линии проектного менеджмента, QA, сопроводительная документация, но о них я даже не пишу - это вообще отдельный мир.

Каждый из перечисленных этапов оплачивается заказчиком. На начальном этапе может быть несколько потенциальных исполнителей.

Мне удалось поработать на всех этапах, кроме последнего (11) и мне очень хорошо знаком этот процесс изнутри.

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

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

Изменено 7 июля, 2020 пользователем andrey_p