В дебрях водопада
Dec. 29th, 2013 11:28 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_rЭтот пост скопирован с поста в LJ вручную из-за проблем с автоматическим переносом.
Заметил, что на эфемерность существования специалистов по requirements engineering жалуются в основном люди из индустрии информационных технологий, в просторечии называемые программистами.
Страховые математики, электрики, электронщики, конструктора как-то без особых проблем выясняют потребности, составляют документы и разбираются с тем, что нужно клиентам, чего они хотят и что им может понадобиться.
В ИТ тех, кто может работать на уровне отличном от «Потыкайте в это окошечко и скажите, что вам не нравится», встречал очень редко, хотя как раз в этой области больше всего и крутился.
Можно было бы говорить про сложность программ, про молодость индустрии, про новизну методик, если бы требования на софт, железо, электронику и механику на самом деле разительно отличались. По сути, специфика начинается при углублении на более низкие уровни. Общие требования, в принципе, если не одинаковы, то аналогичны. Но электронщики и конструктора их составить могут, а специалисты по ИТ - нет.
Похоже, проблема чисто психологическая. Чтобы сделать коробочку и прикрутить её к корпусу надо не просто набрать гору чертежей, но и постоянно общаться с людьми, конструирующими этот самый корпус, технологами, которые отвечают за производство, экономистами, ставящими нереальные требования по бюджету, электронщиками, которые делают для коробочки начинку, и ещё кучей другого народу. Плюс с напильником, верстаком и отвёрткой, потому что всё в конечном итоге проверяется на реальной модели, естественно, коллективно, а не в гордом одиночестве.
Айтишник может неделями работать, без личного общения с другими участниками проекта. Что-то превышающее перекидывание друг другу файлов, тикетов, мейлов и багрепортов считается излишним. Иногда рабочие разговоры возникают, но касаются каких-нибудь хитростей в применяемых тулах, а не способов решения самого задания. Всякие митинги и ревью воспринимаются как тяжкая повинность и проходят с соответствующим результатом. Есть отдельные отклонения, но они погоду не делают.
Как-то присутствовал при разговоре заказчика с айтишным менеджером. На вопрос, когда будет готово техзадание, тот ответил, что всё почти написано и будет выслано для проверки точно к сроку. На что заказчик немного удивился и спросил, какого хрена и каким, собственно, образом пишется спецификация на новую систему, если с вопросами о потребностях, задачах и требованиях к его отделу за три прошедших месяца исполнитель не обращался ни устно, ни письменно. Айтишный менеджер увидел в этом какую-то проблему? Фиг. Ну не доработали, так получилось. Раз хотите, устроим вам какой-нибудь митинг.
Видимо, основную роль играет отсутствие опыта общения с двуногими прямоходящими. Если прибавить сюда типичную склонность к аутизму, становится понятно, почему таким мученическим подвигом представляется банальный разговор о задачах, потребностях и возможностях, и почему requirements engineering в исполнении специалистов по информационным технологиям начинается со слов «Когда заказчик напишет...»
Заметил, что на эфемерность существования специалистов по requirements engineering жалуются в основном люди из индустрии информационных технологий, в просторечии называемые программистами.
Страховые математики, электрики, электронщики, конструктора как-то без особых проблем выясняют потребности, составляют документы и разбираются с тем, что нужно клиентам, чего они хотят и что им может понадобиться.
В ИТ тех, кто может работать на уровне отличном от «Потыкайте в это окошечко и скажите, что вам не нравится», встречал очень редко, хотя как раз в этой области больше всего и крутился.
Можно было бы говорить про сложность программ, про молодость индустрии, про новизну методик, если бы требования на софт, железо, электронику и механику на самом деле разительно отличались. По сути, специфика начинается при углублении на более низкие уровни. Общие требования, в принципе, если не одинаковы, то аналогичны. Но электронщики и конструктора их составить могут, а специалисты по ИТ - нет.
Похоже, проблема чисто психологическая. Чтобы сделать коробочку и прикрутить её к корпусу надо не просто набрать гору чертежей, но и постоянно общаться с людьми, конструирующими этот самый корпус, технологами, которые отвечают за производство, экономистами, ставящими нереальные требования по бюджету, электронщиками, которые делают для коробочки начинку, и ещё кучей другого народу. Плюс с напильником, верстаком и отвёрткой, потому что всё в конечном итоге проверяется на реальной модели, естественно, коллективно, а не в гордом одиночестве.
Айтишник может неделями работать, без личного общения с другими участниками проекта. Что-то превышающее перекидывание друг другу файлов, тикетов, мейлов и багрепортов считается излишним. Иногда рабочие разговоры возникают, но касаются каких-нибудь хитростей в применяемых тулах, а не способов решения самого задания. Всякие митинги и ревью воспринимаются как тяжкая повинность и проходят с соответствующим результатом. Есть отдельные отклонения, но они погоду не делают.
Как-то присутствовал при разговоре заказчика с айтишным менеджером. На вопрос, когда будет готово техзадание, тот ответил, что всё почти написано и будет выслано для проверки точно к сроку. На что заказчик немного удивился и спросил, какого хрена и каким, собственно, образом пишется спецификация на новую систему, если с вопросами о потребностях, задачах и требованиях к его отделу за три прошедших месяца исполнитель не обращался ни устно, ни письменно. Айтишный менеджер увидел в этом какую-то проблему? Фиг. Ну не доработали, так получилось. Раз хотите, устроим вам какой-нибудь митинг.
Видимо, основную роль играет отсутствие опыта общения с двуногими прямоходящими. Если прибавить сюда типичную склонность к аутизму, становится понятно, почему таким мученическим подвигом представляется банальный разговор о задачах, потребностях и возможностях, и почему requirements engineering в исполнении специалистов по информационным технологиям начинается со слов «Когда заказчик напишет...»
Важные цитыты из комментариев
Date: 2018-12-29 07:37 pm (UTC)Люди на мейл из четырёх абзацев могут убить весь рабочий день, причём испытывая особые проблемы с вводной и заключительной частью.
...
Проблема в том, что тулы не дают просто написать названия полей в таблице, а требуют дать точный тип, параметры и пр. В результате мне пришлось рисовать в PPoint, чтобы было быстро и наглядно. Фанатичные программисты забираются в тулах в дебри подменю и теряют связь с реальностью.
...
Люди не могут "любые типы", они начинают сочинять Правильную Систему. А потом другие берут это как руководство к действию.
...
Это подходит для культуры, где случайно сгенерённая диаграмма не является документацией. Как только программисты видят int, - всё. Замена на long int потребует многочасовых выяснений отношений. Плюс менеджеры думают, что всё уже готово - схема базы данных есть.
Так что я предпочитаю просто рисовать. А, когда надо было думать, как данные из промежуточных баз попадают в кубы, я просто напечатал картинку и раскрасил акварельной краской. Была бы возможность, прямоугольники и стрелочки тоже бы сделал кривыми. Чтобы draft версия выглядела как draft.
...
Нужен тул, который позволяет строить неполные диаграммы. Из перебранного в одном проекте полностью удовлетворил задачи только PPoint
...
В любом сложном проекте сначала делается очень приблизительная схема, а потом уже начинается уточнение деталей. Тем более, что детали на диаграмме только мешают наглядности.
То, что CASE тулы этого не могут просто не даёт возможности применения их в сквозном процессе. Тем более, что на этапе, когда надо заниматься мелочами, написать то же самое на SQL, а потом поднять в туле в прямоугольнички, значительно проще.
...
Работа начинается не с проектирования базы, а с общения с клиентами и стейкхолдерами. Ни один тул это не поддерживает.
...
Это очень серьёзный баг в юзабилити. Тип должен быть undefined или TBD, а не случайный.
...
Угу и надо писать что-то вроде int? или TBD: (int or long)
И любое развитие проектирования идёт от ничего не обязывающих до полностью определённых. Тулы позволяют только частично полностью определённые создавать.
...
Всё можно. Но в тех тулах, что я смотрел, это получается через жопу. Чем терять время, проще взять обычную рисовалку.
...
Это не разные области деятельности, а этапы последовательного продвижения.
Причём, в определённый момент времени состояние уточнения для разных частей диаграммы может быть разное.
Все тулы впрягают лошадь позади телеги.
...
Когда я наблюдал за инженерами, у них перед САПРами идёт карандаш с бумажкой. На этом уровне и идут основные обсуждения. Архитекторы - те вообще из картона и глины домики строят, а потом уже в тулы лезут.
В принципе, советую на эту тему посмотреть последние лекции курса Design: Creation of Artifacts in Society by Karl T. Ulrich Особенно, про прототипы. Впрочем, айтишником полезно практически всё, включая технологии и историю стартапа.
...
Остаётся только вспомнить, когда в последний раз я ясный код видел.
...
Техническое задание - это проблема исполнителя. Это ему нужны деньги заказчика. А платить за фигню, которая ему не нужна, заказчик совершенно не обязан.
Разве что его надули, подсунув кривой договор или подписав на agile.
...
Зависит от целей. Плюс от способностей, которых в большинстве случаев страшный дефицит.
...
Мутность техзадания создаёт простор для маневра. Исполнитель может пропихнуть всякую муть или растянуть бюджет в два-три раза. Заказчик может заставить сделать кучу дополнительной работы бесплатно.
По чёткому и однозначному техзаданию одной стороне придётся делать, а другой оплачивать всё по-честному.
...
В этом году видел много техзаданий на геостационарные спутники. Очень чётко и подробно всё расписано. Один мужик сказал, что некоторые заказчики даже влияние Юпитера и Сатурна учитывать требуют. Хотя, это уже паранойя. Правда, написание этого дела само по себе является достаточно серьёзным проектом.
Для Дойчебана тоже был в проекте, единственной целью которого было написание техзадания на софтверную систему.
no subject
Date: 2018-12-30 06:03 am (UTC)no subject
Date: 2018-12-30 08:00 am (UTC)А так, во многих случаях к началу сбора требований клиентам уже продано какое-то решение и в спецификации менеджмент хочет видеть то, что фирма может сделать, а не то, что клиентам нужно. Как правило, цена в контракте занижена раза в два по сравнению с реальной.