Comments 37
Это попытка угадать чужие мысли
Мне иногда приходится работать системным инженером, и в общем это основная задача - именно угадать мысли. Дело в том, что зачастую у заказчика есть лишь, скажем так, "ощущение" того, как должна работать программа, точнее программно-аппаратный комплекс. Он не профессионал в том, чтобы сформулировать, хотя очень старается, даже пытается интерфейсы и кнопочки изобразить. Задача профессионального системного инженера - облечь эти "ощущения" в форму строгих технических требований, причём реализуемых за разумное время (некоторые считают, что ИИ может всё, но нет). Это очень интересно на самом деле и большое искусство довести проект до финала, в котором выглядеть он будет совсем не так, как дилетантски представлял себе заказчик, но который скажет "да, это именно то, что мне нужно, ни больше не меньше", да ещё и уложившись в сроки. Я поначалу пытался всё переусложнять, но по итогу пришёл к "чем проще тем лучше", хотя бывает непросто облечь сложные вещи в простую форму. Ну и итеративность важна, начиная от грубого MVP надо двигаться к детальному конечному продукту, попутно борясь с менеджерами, которые хотят на стадии MVP остановиться.
А так программисты сходят с ума, конечно, можно Терри Дэвиса вспомнить или грустный эпилог в одной из книг, Макконнелла, кажется.
Задача профессионального системного инженера - облечь эти "ощущения" в форму строгих технических требований
Это как раз не задача системного инженера и даже не системного аналитика, задача бизнес-аналитика.
У меня был случай, мы сделали приложение (десктопный клиент), которое большую часть вычислений делало на сервере, заказчик сказал что видел это "немного по другому". Переписали на вычисления на стороне клиента и откидывание метрик в бэк. Снова не то... Привлекли бизнес-аналитика и после его вопроса "мы делаем приложение, что бы что?" разработка остановилась, потому что заказчик так и не смог дать внятный ответ
В принципе да, но это немножко от индустрии зависит, у нас софт — это лишь часть сложной промышленной системы, и они бывают "универсальные" под многих заказчиков, либо "кастомизированные" под конкретного. В основном бизнес-аналитик составляет маркетинговую функциональную спецификацию под "универсальные" продуктовые линии, которой потом следует системный инженер, а вот если это система заточена под конкретного заказчика, то тут как раз системный включается почти сразу, а бизнес аналитик лишь "посматривает через плечо", как некоторые части сделать по возможности "универсальными", этакий "задел на будущее", ну и очень часто такие системы обкладываются NDA (на какой-то срок) и патентами, потому что заказчик не хочет, чтобы конкуренты получили что-то похожее, так что их выкатывать на общий рынок какое-то время не получится (либо вообще никогда). Но кастомизированные, созданные в нескольких экземплярах, системы сильно интереснее универсальных, потому что бизнес практически не ограничивает инженерный полёт мысли, причём со стороны заказчика тоже, так что у него куча "хотелок", и он в общем имеет на них право, потому что за такую разработку он платит охрененные деньги (речь о семизначных суммах, и отнюдь не рублей).
которая должна работать стабильно
пока не получается
Не помню точно но кто-то сказал - " Глобальная задача человечества заключается в борьбе с энтропией" вот мы и боремся)) В конечном итоге, на продукт может повлиять только программист, который пишет его и ему приходится делать поправку на факапы , уровень интеллекта вышестоящего руководства и экономическую ситуацию. Это уже давно норма.
"Глобальная задача человечества заключается в борьбе с энтропией"
Насколько помню: "В любой системе, без приложения внешних усилий, энтропия повышается "
Абсолютно верно, мы всегда в физтехе, когда выпивали, то за энтропию тосты непременно поднимали.
Вообще это применимо и к разработке ПО, вот Джонатан Эдвардс (Jonathan Edwards) как-то замечательно написал "…programming is a desperate losing battle against the unconquerable complexity of code, and the treachery of requirements", и в том что «программирование — это отчаянная, заведомо проигрышная битва с непобедимой сложностью кода и коварством требований» — в общем вся суть, квинтэсенция, так сказать, программирования.
как по мне доступные способы звуко и видеофиксации сделали для ментального здоровья системных инженеров больше чем все психологи мира
не перечесть сколько нервов сберегла фраза "у нас есть запись согласования, делали строго по согласованному"
Мне как-то на аргумент - ваша жалоба это запрос на новую разработку, "мы делали по коментарию номер 123 с 45 страницы согласованного вами ТЗ". Ответили - "Ну это же одна строчка". И зачем-то ожидали сочуствия.
бумажки это все от лукавого
а вот когда голосом все проговаривается и вы явно задалбываете вопросами так ли это, вы уверены что больше ничего и тд - вот тогда настояший дзен
сейчас еше AI появился который может вежливо сформулировать ответ на такие претензии никого не оскорбив
у нас есть запись согласования, делали строго по согласованному
Переносить все риски на заказчика не профессионально. Всё верно, но если вы станете в позу и не сделаете как надо, то Вам больше ничего не закажут при таком подходе.
если заказчик идиот то это не лечится
потому и существует согласование ТЗ что бы перед всеми работами получить полную картину и убедится что мы с клинтом на одной волне. если человеку сначала пофиг "ведь вы же специалисты, сделайте как правильно" то все правки уже потом по отдельному ТЗ с согласованием.
самое печальное что действительно есть клиенты которы пришили за "ведь вы же специалисты" но такие звери очень редкие и они всегда принимают мелкими кусками так как всегда в процессе приема появляются новые идеи/виденье для ТЗ следуюшего
Как вы выжили вообще?
Вы же так со всеми заказчиками разругаетесь
Не по отдельному ТЗ, а в рамках того же контракта в рамках буфера на адаптацию, опытную эксплуатацию или как угодно, хотите назовите его ЧТЗ, ДТЗ, но бюджет превышать нельзя. Если вам нужны дополнительно деньги, а заказчик умеет только в годовой бюджет, то вы в тупике
Как говаривал мой босс, потребитель этот такой, сам ТЗ не сможет составить, не технари. Придется вам помочь :)
Никто и не возражает - "сделать как надо", но если "надо" задним числом на 180 градусов разворачивается - за это заказчик должен платить, а не те, кто делает, логично?
Должен платить.
Но это условно нормальное событие. И это должно быть предусмотрено заранее и желательно забюджетировано.
И исполнитель не должен бросить заказчика в таком состоянии, когда система по ТЗ сделана, но заказчик пользоваться ей не может потому что что-то на старте не предусмотрено.
Такой фигнёй (всё по ТЗ без гибкости) занимались ERP внедренцы, особенно sap. Рынок негативно отнёсся к таким внедрениям.
Я играл в бюджетированные задачи, и да - лучше всего они решаются через рамочные контракты, когда где-то перебор, где-то недобор, и разница по году учитывается предоплатой за следующий год - чтобы неосвоенного не оставалось, или уходит в допсоглашение с оплатой в следующем году - если перебор случился (это больно, но не так, как работа за бесплатно)
В госах хуже всего:
44-ФЗ/223-ФЗ требуют фиксированного ТЗ и цены на старте, изменения почти невозможны
Годовой бюджет жёсткий, неосвоенное сгорает, перенос между статьями сложный
Конкурс выигрывает минимальная цена, потом подрядчик добирает через допсоглашения (обычно, джин уточнение ТЗ без изменения цены) и низкое качество
Обходы которые видел:
Дробление на мелкие контракты по этапам (формально разные закупки, но тут риск что контракт на второй этап ты не получишь)
НИР/ОКР как discovery (там допустима неопределённость результата)
Госкорпорации и ФГУПы как прослойка: они по 223-ФЗ гибче и могут создать субподряд
В целом гибкая разработка в госах работает либо через серые схемы, либо в структурах типа Минцифры/ДИТ Москвы, где (говорят) научились управлять рамочными контрактами. Системно проблема в госах не решена нигде.
Нормальный текст. И по делу и со знанием дела. Плюсую.
Но вот что интересно: откуда столько минусов? Не похоже, чтобы их ставили те, кто оставил комментарии: последние вполне доброжелательны. Кому автор прищемил хвост?)))
Не могу поставить плюс публикации.
Заблокирована возможность оценить эту статью.
Почему?
Может, вы израсходовали плюсомёт? Вроде там ничего не заблокировано. Попробуйте сейчас ещё раз, я вам патрон добавил...
Спасибо. Всё равно не получается проплюсовать пост.
В карму автору плюс поставил.
Это было без проблем возможно.
Вижу что у меня есть возможность ещё 7 оценок в ближайшие сутки в карму и за публикации поставить.
Сложная система 🤔
поделился плюсиком - подтверждаю - не заблокировано, а парабеллума свободного нет?
Тоже хочу плюсануть и не могу. Что за жизнь…
Я полагаю, что подача материала несколько, скажем так, своеобразна, если быстро скроллить, я вот потом вернулся и ещё раз прочитал, да, там есть зёрна, и даже понравилось. Ну а кому то не понравилось, только и всего.
Думаю многие недовольны тем что текст писал/сильно редактировал ИИ.
Быстро пробегают глазами видят признаки ИИ слопа и минусуют.
Ну и содержание в общем-то - просто нытьё , не вижу пользы от него
Статья - в стиле Маяковского 🙂 Плюс в карму! 👍🙂
Это попытка угадать чужие мысли
Немедленно вспоминается 2000 год, 1Сv7.5 и бухгалтер одной небольшой но очень живой фирмы и мой шеф, возжелавший урвать чуток денег на поприще поддержки 1С. Началось всё "просто": сделайте мне просто кнопку "расчитать ЗП" и всё. После почти месяца теребления (а значит отвлекания от текущей работы, которую никто не отменял) выходит преальфа документа. Бухгалтер жмёт кнопку, вроде всё ОК и красиво, расходимся но с согласованием возможных допилов в течение недели. А потом начинается почти каждый день в течение полугода:
- А тут оказывается не правильно считает одну сумму из-за такого-то коэффициента. А чего сразу не сказали? А забыла, он в отпуске был.
- А тут неверно считается высчет алиментщика, месяц сменился и должен быть другой коэффициент.
- А тут у нас договорники и у них другие вычеты соц пакета. Да, ещё про контрактников незабудьте.
И т.д. и т.п. А потом налоговая резко сменила план счетов и мой шеф просто спрыгнул с этой темы ибо по юридическим документам всё было сделано вовремя и давно, а помогали по собственной инициативе а сейчас "нет времени". Я тогда чуть бухгалтером не стал, усваивая эти все тонкости.
но с согласованием возможных допилов в течение недели. А потом начинается почти каждый день в течение полугода
В чем была проблема сказать - неделю поддерживали ,как договаривались, хотите дельнейшей поддержки, платите за нее отдельно. Это, кстати, с 1С обычно нормально воспринимается, сам раньше так зарабатывал. А работать бесплатно, это глупо просто.
Текст сильно пахнет нейронками, но по содержанию всё же хорош.
После одного такого наблюдения я вообще переделал логику:если категории нет — она создаётся прямо во время ввода.
И в итоге получил 100500 дублирующих друг друга по смыслу категорий с немного различающимся по написанию названием..
Очень сильно напоминает опубликованное 21-м часом ранее: https://habr.com/ru/articles/1035386/
Почему программисты не сходят с ума(и почему иногда всё же сходят)