Я экономист, и иногда я люто завидую программистам и инженерам. Если ты хочешь их напрячь - они требуют (и вполне справедливо) ТЗ согласованную всеми заинтересованными сторонами и в письменном виде. В моей работе про это заикаться неприлично. Поясню почему.
Достаточно часто мне ставят задачи в виде, например, а посчитай-ка во что нам обходится содержание узла связи и не надо ли его на аутсорсинг передать, или например, а посчитай-ка, друг любезный, затраты на содержание зданий и сооружений в разбивке по каждому объекту, или вот риски проекта оцени-ка, #тыжэкономист ТБМ! (сразу вспоминаю, а ты мост построить можешь? нет? а почему, тыжинженер!). При этом никого не волнует а есть ли такая аналитика в учетных (бухгалтерских) системах, по какому принципу (методике) я должен отобрать данные, да и вообще никто из заказчиков не утруждается элементарно разъяснить понятия (сделать тезаурус). Что значит узел связи - это персонал? Или еще и совокупность оборудования, тянущая за собой затраты на его содержание? Или это еще и помещение в здании? И вот тут на попытку заявить, а скажите-ка мне любезный Заказчик (а лучше дайте в письменной форме) что Вы под этим понимаете, идет волна негодования - чегой-то ты от нас хочешь, мы тебе поставили задачу и делегировали полномочия, иди и решай!
Или вот второй пример, казалось бы ну всем же понятно что такое расходы на содержание зданий и сооружений. Ан нет! Тут стопитсот мнений может быть, например, один исполнитель (квалифицированный специалист, не мальчик после колледжа) считает что вся электроэнергия "вошедшая" в здание должна включаться в состав расходов на содержание, а второй утверждает, что надо вычитать нагрузку производственного оборудования, так как это расходы на бизнес (на деятельность), а не на содержание, а третий с пеной у рта кричит что все вы долбодятлы и вообще надо подходить к этому вопросу с точки зрения наличия/отсутствия индивидуального узла учета, на нет какгрицца и суда нет!
По логике вещей, тот кто ставит задачу является Заказчиком определенной работы и именно его задача сформировать к ней требования, определить единую терминологию и систему координат для всех соисполнителей... Но не в случае с заказом экономических расчетов. Тебе заказчик просто говорит ну ты посчитай как-нибудь, все равно в этом никто кроме тебя не рубит... А потом начинается цирк, а чегой-то как много денег на станцию??? А-ааа, всепропалошеф... А давай пересчитай как-нибудь чтоб раза в два поменьше затрат было... Ну сам там подумай как будет оптимальнее, а я тебе все полномочия даю...
Вот оказывается как! Отказ от ответственности составить хотя бы минимальное ТЗ (хотя бы тезаурус) - это теперь делегированием полномочий называется. Попробуйте-ка провернуть такой фокус с инженером, скажите мне надо построить мост! Какой мост? Что значит какой? Ну там, высота, длина, ширина, автомобильный или железнодорожный? Да что ты мне голову морочишь, иди и сам разберись!
Мне это напоминает анекдот про парикмахерскую. Заходит клиент, его спрашивают как Вас подстричь? А какие варианты бывают? Ну там, теннис, бокс, полубокс, ежик, зеро (налысо) ... О, вот! Давайте зеро!... Подстригли, посмотрел в зеркало, говорит - не, не нравится, давайте полубокс.
Вот здесь Уважаемый СеВа четко сформулировал одну из проблем века - отказ от ответственности. В первую очередь отказ от ответственности руководителя организовать работу. Неистово плюсую! Но добавляю к этому еще один немаловажный аспект, в наше время двойных стандартов и смыслов, множественности сленгов и терминов, категорически необходимо начинать любую работу с того, чтобы стороны договорились что они понимают под тем или иным действием и явлением. Чтобы исполнитель отвечал за результат своего труда, заказчик должен отвечать за качественную постановку задачи. Вот тогда будет меньше тупых работников(подчиненных) и козлов-заказчиков(начальников)!
Комментарии
Извечная проблема Заказчик-Исполнитель. Знаю не понаслышке.
Я в таком случае начинаю общаться с заказчиком и выясняю наводящими вопросами что и как ему надо.
В крупных конторах (которые работают непосредствено с заказчиками а не аутсорс аутсорса) - у программистов есть специально обученные переговорщики, которые помогают клиенту сформулировать и формализовать чего ему именно хочется, и оформить это во внятное ТЗ.
А ещё объяснить и заинтересовать новыми фичами, которые обязательно ему понадобятся в следующих итерациях, за отдельные деньги.В некоторых, работающих с документооборотами, например - есть ещё и специальные отделы документоведов, чтобы описанная в ТЗ система была ещё и юридически значимой, и прочее. Аналогично, наверное, во всех специализированных конторах.
В мелких конторах и во фрилансе - это всё совмещает обычный программист. Если требовать с заказчика полное ТЗ сразу - скорее всего он вас пошлёт и уйдёт к более дружелюбным. Поэтому приходится оттачивать скилл понимания "что он этим хотел сказать", и уточнять, повторяя ему его же слова но в формализованном виде, предлагая выбор из уже сформулированных вариантов итд.
Так что у программистов тут тоже нет полного счастья, если за них не выполнит работу по формализации ТЗ специально обученный человек)
Таки даже если есть аналитик ( прокладка между клиентом и программером). Там тоже не все гладко. Испорченный телефон и прочие прелести.
Это да) В теории, где-то должен существовать идеальный бизнес-аналитик, который может всё внятно сформулировать и согласовать с первого раза... Не встречал)
отлично!
У этой картинки скоро внуки пойдут уже :)
Именно. Зачастую ещё окажется, что типовое решение вполне устроит. Ну или сперва его предложить, дать возможность помучиться и сказать, чего не хватает. Хуже того, были случаи, когда при постановке задачи чётко указывал на возможные сложности и требовал уточнения. И получал, и делал согласно ТЗ. а потом выходило так, что надо было делать по тому варианту, что сам считал оптимальным. Я так году в 2008-м закурил - после пары подобных случаев.
Так что, крик души очень даже понятен.
Ещё и с десятикратным запасом по функционалу)
Угу, аналогично. В итоге вроде прокачал скилл говорить много слов и неявно подводить к тому "как надо", и как оптимальнее сделать с моей точки зрения.
Ха ха не завидуйте, там тоже самое :) Вот прямо слово в слово.
Не завидуйте. У нас в 90% случаев такая же беда ((
Да, зря ТС завидует. Так везде, где нет ответственности за освоение бюджета или нет ответственности за результат. В других местах, где есть ответственность, либо не будут ставить задачу в таком виде, либо не возьмутся исполнять задачу в подобной постановке.
Заказчик должен полностью разбираться в существующих технологиях, точно представлять себе трудоёмкость той или иной фичи, и точно знать стоимость программистов нужной для этого квалификации? Картинка внизу очень хороша.
Или заказчик таки приходит с общими хотелками, и уже затем пишется и подписывается совместными усилиями сторон что-то похожее на ТЗ?
"Заказчик должен полностью разбираться в существующих технологиях, точно представлять себе трудоёмкость той или иной фичи, и точно знать стоимость программистов нужной для этого квалификации?"
Это даже во влажных розовых снах не снится... Достаточно, чтобы он знал и озвучил ВСЕ свои "хотелки" в подробностях до момента начала работы программиста.
Именно так, камрад, именно так - только СВОИ ХОТЕЛКИ. Свою часть работы я знаю хорошо и сам решу как наиболее рационально и оптимально хотелки удовлетворить, при этом проверю их на взаимную непротиворечивость... лишь бы они были озвучены максимально (не все, такого не бывает).
А в программировании часто случается такое что заказчик не до конца знает что можно сделать. Довольно частая ситуация "А что, так можно было? Тогда да, очень нужно."
" Просто крик души "
Вам, как экономисту, должны были разъяснить, что перестройка (не к ночи будет помянута) была затеяна ради двух вещей - Присвоение, с передачей по наследству, украденного и ОТСУТСТВИЕ ОТВЕТСТВЕННОСТИ ЗА ЛЮБЫЕ ДЕЙСТВИЯ.
Не подумайте что хвастаю, но вот буквально тройку месяцев назад мы коллективом сваяли ТЗ на АРМ руководителя ФЭБ (в чине ЗГД) в объеме около 100 листов, расписав и визуализацию интерфейса (в паверпойнте) и источники данных (регистры 1С, базы данных внутренней системы планирования и т.п., сетевые ресурсы), формы отчетов (в экселе), быстрые кнопки и т.п. И считаю что этого даже мало мы написали, но хотя бы дали программерам точку старта, с чего начать... Только так правильно поступать с людьми, которым ты поручаешь что то сделать...
Если человек представляет себе хотя бы направление движения и первые шаги, то задачу он худо-бедно начнет решать. Если этого нет, то тысяча и одна сказка найдется чтобы даже не начинать. Это основы психологии про ловушки сознания.
Я программист. Последний раз ТЗ я не видел некогда. Максимум листочек с пожеланиями что они в моей программе хотели бы увидеть. Попытка напрячь с этим заканчиваются предложением что бы я сам его и написал. Причем я то могу это сделать, но мне за это разумеется не кто не заплатит. И смысл.
та же беда... и глаза кота из Шрека от заказчика... как бесит, особенно когда я даже в теории не понимаю, что от меня хотят (последняя хотелка - монгольский финансовый учет)
Да грустно.
Делай что сказал купец, вот и будешь молодец,
а поссоришься с купцом вот и будешь ты глупцом.
:).
Не царёво дело ТЗ с тезаурусами сочинять
- Проект - готов?
- Все сделано по ТЗ.
- Так не было же ТЗ!
- И проекта - нет.
И денег тоже нет.
Заказчик любит платить за результат работы. ТЗ это не результат. По уму на стороне заказчика должен быть специалист способный написать такое ТЗ и грамотно принять работу. Но такого специалиста не когда нет поэтому мы имеем то что мы имеем.
Как раз детально проработанное ТЗ – это один из главных результатов проекта.
Обычно различают конкурсные, "входные" ТЗ и ТТ (Технические Требования), затем, уже во время исполнения проекта разрабатываются ЧТЗ – Частные Технические Задания и ТП – Технический Проект.
В течение проекта происходит этап технического проектирования: подрядчик детально проектирует автоматизированную систему и согласовывает решение с заказчиком (результаты – ТП и ЧТЗ).
На этом же этапе формируются ЧТЗ для тех подсистем, ПО, технических средств, которые не являются покупными изделиями и должны быть РАЗРАБОТАНЫ (доработаны) либо самим подрядчиком, либо (что чаще) субподрядчиками.
Программирование идет по мере утверждения вариантов/частей ТП и ЧТЗ.
Если Заказчику еще во время формирования контракта нормальным доступным языком объяснить схему взаимодействия, этапности получения результатов (включая ЧТЗ и ТП) и оценки стоимости работ, то вполне все гладко происходит.
Тем более, что в формировании ЧТЗ и ТП как правило принимают совместное участие и специалисты/аналитики проектной команды со стороны Заказчика – за что им тоже платят. И Заказчик шаг за шагом, с подтверждением от своих специалистов, убеждается в необходимости формирования и оплаты таких проектных документов.
Не завидуй.
Вы как-то слабо представляете себе работу инженера. Либо идеализируете излишне. В реальности так и происходит: "Сделайте мне мост. Какой мост? Ну обычный, чтоб на машине через ту речку ездить". В IT такое сплошь и рядом. Понять что и зачем нужно заказчику - это часть работы исполнителя. Потому что как правило тот, кому нужен мост, о мостах знает довольно мало, у него вообще о другом голова болит.
Тут ведь еще дело вот в чем... если вы рядовой винтик, то над вами есть кто-то, кто эти вопросы порешает и вам останется только ваша инженерная работа. Но стоит чуть-чуть вырасти карьерно и все, кончилось счастье.
Безусловно вы правы, я утрировал. но все же у инженеров есть нормы и правила, есть конструктивные и материаловедческие ограничения, а вот труд экономиста он сродни работы математика... У бухгалтера есть правила бухучета и законы, а нам закон не писан и сам черт не брат. Могу рассчитать хоть сферического коня в вакууме. Это кстати к вопросу как наши коллеги в минэкономразвития работают :)
Друзья и коллеги, уже прочитавшие мой опус (как раз программист среди них нашелся и инженер-расчетчик), сказали что я ошибся с выбором объектов для зависти. У них все то же самое - сделай то, не знаю что, но чтоб удовольствия от этого было море!
Вот это что, национальная черта? Или даже у немчуры так же?
Все равно это не отменяет главный тезис - давайте договариваться на берегу кто гребет а кто огребает, до того как лодка отплыла...
не черта, традиция, отрицательный отбор, кумовство, хоть как называйте. Некомпетентность любого уровня начальства компенсируется засиранием мозгов инженерному составу и его эксплуатацией. Лечится подсиживанием такого полуначальства, но мало кто способен из инженеров на такое, все ведь высоконравственные или трусливые.
Дело не в нравственности и не в трусливости. Инженеру просто легче сменить работу, чем не подсиживать..
Ой, да почему ж национальная? Те же американцы в том же IT придумали agile, они же гибкие методы разработки, чтобы сделать хоть что-то с неумением заказчиков составлять ТЗ. Получилось так себе. Везде бардак. =)
У буржуев тоже самое. Это цивилизационное или даже обще человеческое. Можете открыть Иланс, почитать задачки по вашей сфере :)
P.s единственное отличие, цена часа работы высокая. Это остужает горячие головы малька.
У програмистов есть специальная стадия. Называется сбор требований. Разбивка на функциональные и бизнесс требования, требования к инфраструктуре и так далее и так далее. И это нормальный этап работы.
В вашем случае надо спуститься с горы к заказчику и выяснять у него требования. А позиция "мне должны" никчему хорошему не ведет, т.к. вы выступаете со стороны - уговорите меня, разжуйте мне ТехЗадание так чтобы мне было понятно. Хотите стать профессионалом сделайте так чтоб заказчику было с вами удобно и приятно работать. Продумывайте вопросы требования, предлагайте варианты (с плюсами и минусами), уточняйте, и все у вас получиться.
Хорошая заметка. Одно только замечание.
Мне кажется, Вы уделяете чрезмерное внимание личностным характеристикам Заказчиков. А тут налицо недостатки процесса, выглядящего анахронизмом даже для 19 века. .
И это - намного-намного хуже личной безответственности.
Нашли кому завидовать
...извините :-)
У нас тут в среде хм.. финансовых работников (не бухгалтеров!) бытует мнение, что финансовый результат это вообще как бы мнение. Сколько надо, столько и насчитаем. А мнение оно как известно может быть разным в разное время.
Не совсем в тему, но близкое замечание. Я когда только попал из инженерной сферы в экономическую, меня помню дико раздражала одна вещь. В инженерных науках есть законы природы и ты их хочешь - не хочешь, но соблюдаешь. Можешь (если поумнее) использовать во благо, можешь как-то бороться, но вот прямо так взять и нарушить - этого природа в общем случае не позволяет. А в экономике нет законов природы, в экономике все законы и правила людьми придуманы и потому нарушаются всеми кому не лень направо и налево. И нет никакого механизма чтобы запрет сделать абсолютным, как с нарушением законов природы. А жалко.
У меня зам человек редкой остроты ума и слова. Его как то дочка спросила, папа а чем ты занимаешься на работе? он немного подумал и ответил: " Я в некотором роде связан с математикой". Экономиста тоже ограничивают законы - законы математики :)))
Не, таки некий абсолютный финансовый результат таки существует (прибыль - это денежный поток в пределе (предел в математическом смысле)), другой вопрос в краткосрочной перспективе что он всегда считается с допущениями и предположениями (и третий вопрос, что допущения можно делать для повышения точности, а можно для подгонки результата ) )
Это как сложная химическая реакция, и мы как бы можем в любой момент ее остановить и весами измерить, сколько там чего по факту; только проблема сама остановка реакции меняет это соотношение. Прибыль Шредингера, как она есть. Вот и приходится оценивать это соотношение по расчетным, а не экспериментальным путем.
А зависимости есть, только они действуют на более высоком статистическом уровне: вот броуновское движение атомов - хаос как он есть; а на уровне газа - четкие зависимости давления, температуры, объема.
Перспективный чат детектед! Сим повелеваю - внести запись в реестр самых обсуждаемых за последние 4 часа.
ГЫ-ГЫ-ГЫ-ГЫ-ГЫ!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Я экономист, и иногда я люто завидую программистам и инженерам. Если ты хочешь их напрячь - они требуют (и вполне справедливо) ТЗ согласованную всеми заинтересованными сторонами и в письменном виде.
Где эта страна Оз???!!!!
ХОЧУ ТУДА!!!!!
Покажите мне эти райские кущи!!!!!
Особенно, когда идёт разработка того, чего аналогов не существует в природе!
За более чем 35-тилетний стаж программера, я имею 90% случаев (до)оформления ТЗ "задним числом".
Откуда у автора такое благостное понимание мира программирования?
Или он только с вебовцами и базовиками из финансовой сферы общался?
И не то что ТЗ, КД часто оформляется задним числом. Линия производства насосов закрылок СУ тому пример.
Военпреды, этого нет в КД. Ответ, так и КД еще не утверждено, поправим и внесем по факту:)))
Как не утвержено, так если утвердят за разработку КД по договору платить придется:)))
Вот годами и не утверждают. В чертеже пять тысяч пятьсот размеры не госту проставлены и тп.
Вот так и живем...
Самолеты летают, насосы закрылкок выпускают без испытаний вообще (на склад и берут со склада запасы СССР), документация не утверждена чтоб денег не платить. Завод в Уфе досих пор толком не запущен.
Дошло до президента РФ.
Цитата Путина
"Если боевая авиация сядет, сядут даже рядом не стоявшие" (с)
Рогозин
"До Нового Года запустить первую очередь, до весны вторую."(с)
Цитаты на слух, запись не велась
В вы думаете, почему на Западе "конкурсы" устраивают, например, при выставлении требований к "новому поколению" до лётного образца?
А - что бы издержки подобного рода под ковром так и оказались заметенными. Государство, под предлогом развития конкурентной борьбы на основе частной собственности, просто умывает руки, оставляя всё на откуп частникам.
Основное оформление документации победителем начинается потом, как и у нас. Но надо честно признать, что там есть конторы, которые этим профессионально занимаются (оформлением документации по стандартам) и получается конфетка.
А вот когда по госпрограммам проекты выполняются, с отслеживанием прогресса с самого начала - вот там цирка хватает. Начиная от гарантированной просрочки и перерасхода фондов и - до разборок по КД.
Если бы они это сами для себя смогли сделать, то нахрена им экономиста со стороны нанимать.
Описанная ситуация стандартна и банальна. В 99% случаев, мысль, которую до тебя, непонятливого, хотят донести заказчики это: "хотим бизнес вести, как и вели, делать всё как и раньше, от тебя требуется совсем масяяяяявочная малость - что бы при этом у них прибыль была." Им просто нужен козёл отпущения. Что бы за наличие, пусть и минимальной, но прибыли перевести стрелки на себя, за отсутствие таковой - было б на кого показать пальцем.
Тебя ж ясно и понятно попросили посчитать им что бы у них из крана деньга струёй била, а ты им про тезаурусы и техзадания... (а ещё ни дай бог про бизнесс процессы, целеполагания, функции). ))))))))))))
В консалтинге не встречал ни одного миллионера. Все миллиардеры. Если все, кому они проекты делали, деньги заплатят...
Удивительная и импозантная наивность. )))
По поводу программистов/аналитиков вы не правы. У них та же функция, что и у экономистов. Именно поэтому лучше всего получается в этих областях у воздушных/социальных типов по именам и другим параметрам, т.к. они очень быстро соображают и отзеркаливают - достаточно социальны, общительны и быстро соображают для выяснения чего же надо заказчику. И тут дело не в ТЗ, а именно в выяснении до работы, а чего же надо. Т.е. половина задачи экономиста - это работа понимания в общении, а чего заказчик-то хочет...
Страницы