Comments 122
UFO just landed and posted this here
Заказчик всегда получал автоматизацию бух.учета, <...>, необходимость нанять программиста 1С (а лучше двух) и раздутый штат бухгалтеров, экономистов и прочих операторов, которые вместе с программистом 1С становятся придатками системы.
Высокие зарплаты программистов 1С — это не следствие любви бизнеса, а вынужденная необходимость — кто-то должен обслуживать то, что на хайпе навнедряли.
UFO just landed and posted this here
Один известный банкир недавно сказал что программисты не нужны.
Вот пусть и ведет прием людей исключительно в офисах, данные отправляет на бумаге почтой)
Потом можно будет посмотреть, как долго просуществует такой банк в конкурентной среде (если речь идет о госбанке, то он выживет в любом случае, даже при ведении учета в гросбухах).
Потом можно будет посмотреть, как долго просуществует такой банк в конкурентной среде (если речь идет о госбанке, то он выживет в любом случае, даже при ведении учета в гросбухах).
Речь о Сбербанке и Германе Грефе. Странно, что Вы такую хохму пропустили — мы всем офисом катались.
Вот где карту открывали туда и идите.
Такую фразу услышать в поддержке практически невозможно, сейчас она сменилась на «Идите в ближайшее отделение, объясните ситуацию, возможно они смогут вам помочь».
а такую фразу как раз в отделении и говорят, а не в поддержке.
Но вообще в любом отделении того же тербанка свободно можно перевыпустить и получить карту.
Вы пробовали в отделении в области закрыть карту, открытую в Мск? Я — да. Не вышло.
Это всё Среднерусский банк, должны были сделать. Слава богу я не в Москве, но тут товарищи с ЛенОбласти всё успешно делают в Питере, и уже лет пять как. Я точно так же тут всё делаю по картам из Мурманской области (в том числе и закрытие карты). Единственное что мне говорили — иметь карту с собой, потому что они видят только карты своего региона. И был ещё один перекос: деньги со счёта в одном отделении не могли выдать в другом отделении в том же районе города.
В теории оно все так, «должны сделать». На практике у меня было две карты — в области и в мск. К каждой привязан свой онлайн банк. Заходишь в один — видишь все карты и один счет. Заходишь в другой — видишь все карты и другие счета, среди которых нет первого.
И вишенка на торте, после которого я отказался от использования сбера — я не могу с карты, открытой в области перевести деньги на счет, открытый на московском аккаунте через СБОЛ. т.е. я захожу в СБОЛ, вижу и карту и счет и не могу перевести деньги. приходится переводить сначала на московскую карту, а потом на московский счет
И вишенка на торте, после которого я отказался от использования сбера — я не могу с карты, открытой в области перевести деньги на счет, открытый на московском аккаунте через СБОЛ. т.е. я захожу в СБОЛ, вижу и карту и счет и не могу перевести деньги. приходится переводить сначала на московскую карту, а потом на московский счет
А там вместе с оператором звоните в техподдержку и вчетвером (с замом или старшей) пытаетесь разобраться.
Везде, где я работал, сталкивался именно с таким подходом. И это касается не только ИТшников. Любой рационализатор на производстве сталкивается с таким. Поэтому когда я вижу в стране беспорядок меня это нисколько не удивляет. Знаю причину.
Нужен ли именно хороший программист можно понять только из общения с заказчиком. А большая сумма компенсации — это в первую очередь показатель, что компания может себе позволить столько платить, а также то, что компании очень нужен программист вот прям сейчас.
Вам же за это и заплатили уже, второй раз платить, что ли? На тему денег, они ж никуда не деваются, не расхитились на телефонию, будут похерены в другой передовой области. Опять же, смотра за счёт чего вы их сократили и с каким качеством
На самом деле всё очень просто. Бизнес не любит 1Сников, но 1Сников любят бухгалтеры. А не любить бухгалтеров бизнес не может и готов удовлетворять все их капризы. Фактически 1Сника на работу берёт главбух. Как главбух скажет так и будет. Скажет главбух-надо трёх 1Сников-будет три и никто спорить даже не будет-сократят уборщиц, урежут премию, но трёх 1Сников возьмут.
Суррогаты
Разослал статью всем, к чьему бизнесу не равнодушен.
В процессе подключается более мелкий формализм – не будем делать работы сверх бюджета, не будем делать два варианта интерфейса, не будем работать над производительностью, если она ограничена платформой (а кто проверит?).
Ну это только вопрос финансов. Даже не сроков. И это не формализм, это рациональный подход к трате времени не задаром.
По сути, все всегда продают своё, или чужое (нанятое) время (невосполнимый ресурс). Если у заказчика есть бюджет на двойную работу (2 интерфейса вместо одного), почему-бы и не сделать. Однако, тратить время на то что не приносит прибыли, или даже в убытки вводит (сверх бюджета), совсем не разумно. Заказчик чаще всего и цели-то толком не видит. Он хочет кнопку «сделать хорошо», за 0 рублей 13 копеек и месяц работы. У заказчика отделы между собой точно также воюют: одним система вообще не нужна, — она-же их контроллировать будет, другие не понимают зачем это всё если есть Excel и электронная почта, третьи считают, что вся эта автоматизация есть формализм, для того что-бы у них красть время, которое они могут потратить на котиков в «тырнетах».
Главный, наверное, формализм, вы все о нем знаете. Это первый этап производства суррогата. Начинается с фразы «давайте теперь зафиксируем на бумаге».
В любых системах построеных на доверии, это доверие всегда подрывается. Именно поэтому существуют договоры и юристы. Если ничего не «формализировать», то будешь до ишачьей пасхи удовлетворять заказчика в лице лебедя, рака и щуки, причём бесплатно, из любви к искуству.
К 1С я отношения не имею, но насмотрелйся на ситуации когда люди хотят, чего-то одного вначале потом понимают, что хотели чего-то совсем другого и странного, а платить за это не хотят.
Всё понятно, всё правильно сказано, только один вопрос — вас ист дас «франч»?
Вот просто обнять и плакать…
О, да! )))
Я бы добавил еще: «Спасибо, кэп!».
Вставлю/вспомню пять копеек.
Когда в студенческое время собирал народу компу, то общение с заказчиком часто строилось так:
Заказчик — «Нам нужен компьютер»
Я — «ОК, я сейчас буду задавать вопросы и они могут показаться глупыми».
Заказчик — «Э… Хорошо».
Я — "Зачем вам нужен компьютер?".
По моему, на любых курсах по продажам учат в первую очередь выяснять потребности клиента, и это очевидно.
С другой стороны — это легко говорить/делать когда сам всем управляешь.
Как-то принимал участие в одном проекте, задача ставилась так:
Заказчик: — Вам надо сделать ЧАСТЬ 1, другой отдел сделает ЧАСТЬ 2. Все понятно?
Я: — Нет, так нельзя. Обе части надо делать одновременно и одной группе. Я профессионал, я знаю.
Заказчик: — Вам надо сделать ЧАСТЬ 1, другой отдел сделает ЧАСТЬ 2.Такова политика партии. Вы профессионал, вы справитесь.
Обнимаемся и плачем.
Я бы добавил еще: «Спасибо, кэп!».
Вставлю/вспомню пять копеек.
Когда в студенческое время собирал народу компу, то общение с заказчиком часто строилось так:
Заказчик — «Нам нужен компьютер»
Я — «ОК, я сейчас буду задавать вопросы и они могут показаться глупыми».
Заказчик — «Э… Хорошо».
Я — "Зачем вам нужен компьютер?".
По моему, на любых курсах по продажам учат в первую очередь выяснять потребности клиента, и это очевидно.
С другой стороны — это легко говорить/делать когда сам всем управляешь.
Как-то принимал участие в одном проекте, задача ставилась так:
Заказчик: — Вам надо сделать ЧАСТЬ 1, другой отдел сделает ЧАСТЬ 2. Все понятно?
Я: — Нет, так нельзя. Обе части надо делать одновременно и одной группе. Я профессионал, я знаю.
Заказчик: — Вам надо сделать ЧАСТЬ 1, другой отдел сделает ЧАСТЬ 2.
Обнимаемся и плачем.
Не вариант пройти мимо человека смотревшего и ПОНЯВШЕГО догвилль! Держи респект, незнакомый но приятный мне набор пикселей на мониторе!
Что-то такое я уже читал в прошлом месяце на Инфостарте. Ну просто буква-в-букву! :)
infostart.ru/public/703188
И тогда же в вашем личном блоге:
business-programming.blogspot.ru/2017/11/blog-post_23.html
infostart.ru/public/703188
И тогда же в вашем личном блоге:
business-programming.blogspot.ru/2017/11/blog-post_23.html
Дружат с бухгалтерией и пользователями, помогают закрывать месяц, загружают/выгружают файлики
Это вообще не к программисту вопрос, а к менеджменту. Если рабочий процесс организован так, что сотрудники отказываются осваивать собственный рабочий инструмент, а всё время дёргают IT, чтобы они делали за них их работу — это ни разу не проблема программиста. Максимум, что он может сделать — это донести до менеджмента сложившуюся ситуацию. Причём, если менеджемнт поозволяет складываться такой ситуации, то скорее всего в этом случае он получит разнос и пойдёт снова выгружать файлики.
В подавляющем большинстве подразделений иностранных компаний в россии, с которыми мне приходилось работать — есть бюджет на автоматизацию на год. То есть франчу говорят — давайте что-нибудь автоматизируем. Вот сидит тетя и грузит раз в день файл вручную, давайте сделаем чтобы файлы грузились автоматически, а тетя получала уведомления об ошибках загрузки, либо уведомления получал администратор, если за 1 день с момента попытки загрузки файл так и не был загружен.
Вы думаете тетю после этого тетю сократят? Нет, ей просто найдут другое занятие. Автоматизацию приводит к сокращения только, если до этого учет ведут на бумаге низкоквалифицированные сотрудники… Если в компании основные бизнес-процессы уже автоматизированы, высвобожденное время сотрудников будет использовано по-другому — контроллинг, расчет kpi, составление планов и анализ их выполнения. Когда-нибудь и эти процессы будут автоматизированы.
Есть особо продвинутые компании, которые считают, что если проблема возникла по вине человека — то он в этом не виноват, виновата компания, которая не автоматизировала данный участок работы и не прописала в коде необходимые ограничения и проверки.
Вы описываете внедрение 1с в компании, руководство которой пока не понимает цели проекта. Обычно они хотят внедрить сразу все, а в результате часть внедряемого функционала не будет использоваться. Благодаря автоматизации некоторые компании только начинают понимать, что такое процессы, зачем нужна сертификация ISO 9000 и зачем их автоматизировать.
Вы думаете тетю после этого тетю сократят? Нет, ей просто найдут другое занятие. Автоматизацию приводит к сокращения только, если до этого учет ведут на бумаге низкоквалифицированные сотрудники… Если в компании основные бизнес-процессы уже автоматизированы, высвобожденное время сотрудников будет использовано по-другому — контроллинг, расчет kpi, составление планов и анализ их выполнения. Когда-нибудь и эти процессы будут автоматизированы.
Есть особо продвинутые компании, которые считают, что если проблема возникла по вине человека — то он в этом не виноват, виновата компания, которая не автоматизировала данный участок работы и не прописала в коде необходимые ограничения и проверки.
Вы описываете внедрение 1с в компании, руководство которой пока не понимает цели проекта. Обычно они хотят внедрить сразу все, а в результате часть внедряемого функционала не будет использоваться. Благодаря автоматизации некоторые компании только начинают понимать, что такое процессы, зачем нужна сертификация ISO 9000 и зачем их автоматизировать.
Еще хотел бы добавить, что западные компании рассматривают автоматизацию как инвестиционный проект, профит от которого будет до тех пор пока компания существует. Отечественные компании рассматривают автоматизацию как затраты, поэтому хотят сделать все быстро, дешево и часто собственными силами. Хотя зачем развивать собственных ИТ-специалистов, если компания, например, изготавливает мебель.
UFO just landed and posted this here
Хотя зачем развивать собственных ИТ-специалистов, если компания, например, изготавливает мебель.
Работал в компании, которая продает ГСМ. Развивать собственных ИТ-специалистов позволило снизить расходы на ИТ примерно в три раза, при значительном повышении качества услуг. Математика простая: специалист ERP из консалтинговой компании обойдется в $50/час, при этом он, грубо говоря, гость из дальнего космоса. В компании должен быть человек, который собирает пожелания пользователе и формализует их, затем наемный специалист должен въехать в бизнес-процесс, понять, как это должно быть реализовано (при необходимости объяснив пользователям, почему оно будет не так, как они просили), наконец, реализовать/оттестировать/отдеплоить, и снова улететь к себе на Альфу Центавру, или откуда он там прилетал.
Собственный специалист будет получать ставку $15/час (те же $50 минус прибыль консалтинговой компании, минус их налоги, минус их операционные издержки), при этом устраняется лишнее звено коммуникации, вон он тут всегда рядом, возле пользователей, ежедневно сталкивается с одними и теми же процессами, знает все проблемы и перспективы одной конкретной системы. Поэтому если ваши постоянные задачи по сопровождению и развитию ERP-системы способны хотя бы процентов на 70 загрузить работой одного специалиста на фуллтайме, берите его в штат. Так вам будет лучше.
Мне кажется вы путатете внедрение новой функциональности и поддержку существующей. Вот нет, например, в компании бюджетного управления, кто по вашему сможет его поставить? Собственные специалисты почитают книжки, сходят на семинары по бюджетированию, а затем начнут разрабатывать собственное решение или кастомизировать существующее? С огромной степенью вероятности, что при таком подходе вообще ничего не будет сделано или сделано не то, что требуется бизнесу.
Если бизнесу удалось найти специалистов, которые готовы в вникать в новые темы и внедрять новую функциональность, то тактически бизнесу это действительно выгодно. Но возрастают риски, что данные сотрудники могут просто напросто свалить, к тем же самым интеграторам, т.к. там и проекты интереснее и доходы выше. А компания останется с функциональностью, на которую даже нормальной документации нет.
В определенный момент времени у действительно сильных аналитиков и разработчиков возникает потребность получать деньги не за время, а за опыт. Они захотят писать собвенные курсы или делать тиражное ПО. Такие возможности конечный клиент никогда не предоставит.
Возможно поэтому западные компании вкладывают деньги только в развитие компетенций, связанных с основной деятельностью, а все остальное передать другим компаниями. Именно поэтому у них такая высокая доля сферы услуг в экономике, а у нас завод может выпускать откровенное гамно, но зато у в нем может быть отличная столовая.
Если бизнесу удалось найти специалистов, которые готовы в вникать в новые темы и внедрять новую функциональность, то тактически бизнесу это действительно выгодно. Но возрастают риски, что данные сотрудники могут просто напросто свалить, к тем же самым интеграторам, т.к. там и проекты интереснее и доходы выше. А компания останется с функциональностью, на которую даже нормальной документации нет.
В определенный момент времени у действительно сильных аналитиков и разработчиков возникает потребность получать деньги не за время, а за опыт. Они захотят писать собвенные курсы или делать тиражное ПО. Такие возможности конечный клиент никогда не предоставит.
Возможно поэтому западные компании вкладывают деньги только в развитие компетенций, связанных с основной деятельностью, а все остальное передать другим компаниями. Именно поэтому у них такая высокая доля сферы услуг в экономике, а у нас завод может выпускать откровенное гамно, но зато у в нем может быть отличная столовая.
Нет, я и внедрение также имею в виду. В любом случае для внедрения того или иного функционала нужная компетенция должна быть в первую очередь у менеджмента компании. Это они первыми должны читать книжки и ходить на семинары, независимо от того, кто будет внедрять, собственные спецы или приглашенные.
Если брать бюджетирование, к примеру, то у него техническая составляющая всегда более-менее одинаковая, и опытный разработчик в ней разберется за достаточно короткое время. А специфические для бизнеса процессы в любом случае надо будет долго и мучительно прорабатывать/рефакторить вместе с менеджментом и ключевыми пользователями, независимо от того, кто внедряет.
Есть такая стратегия в управлении предприятием — отдавать на аутсорс все непрофильные направления. Но она, скажем так, имеет рамки применения. В общем случае это хорошо работает в двух кейсах:
а) если у компании есть много денег, и нет цели снизить издержки, зато есть цель разгрузить менеджмент
б) если компания маленькая, и постоянные издержки на содержание непрофильных направлений превышают эффект от снижения переменных.
Если брать бюджетирование, к примеру, то у него техническая составляющая всегда более-менее одинаковая, и опытный разработчик в ней разберется за достаточно короткое время. А специфические для бизнеса процессы в любом случае надо будет долго и мучительно прорабатывать/рефакторить вместе с менеджментом и ключевыми пользователями, независимо от того, кто внедряет.
Возможно поэтому западные компании вкладывают деньги только в развитие компетенций, связанных с основной деятельностью, а все остальное передать другим компаниями.
Есть такая стратегия в управлении предприятием — отдавать на аутсорс все непрофильные направления. Но она, скажем так, имеет рамки применения. В общем случае это хорошо работает в двух кейсах:
а) если у компании есть много денег, и нет цели снизить издержки, зато есть цель разгрузить менеджмент
б) если компания маленькая, и постоянные издержки на содержание непрофильных направлений превышают эффект от снижения переменных.
У менеджмента никогда не бывает времени для приобретения новых компетенций, у него и без этого задач хватает.
Ну если у бизнеса есть ресурсы проторивать дорогу к результату методом проб и ошибок — ради бога. учитывая состояние нашей экономики, большинство компаний именно этим и занимаются.
Ну если у бизнеса есть ресурсы проторивать дорогу к результату методом проб и ошибок — ради бога. учитывая состояние нашей экономики, большинство компаний именно этим и занимаются.
У менеджмента никогда не бывает времени для приобретения новых компетенций, у него и без этого задач хватает.
Вообще-то как раз строго наоборот, это одна из его первоочередных задач, и если менеджмент не приобретает новые компетенции, значит, он не развивает компанию. Если компания не развивается, её выбрасывают с рынка те, кто развивается.
Развитие компетенций менеджмента обычно лежит в области менеджмента а не техники. Управление людьми и процессами гораздо более сложная история, чем программирование.
Чтобы поставить технарям задачу на реализацию какой-то системы или фичи в существующей, у менеджмента должно быть достаточно компетенций, чтобы, хотя бы, знать о том, что эту задачу в принципе можно решить, чтобы мысль о реализации вообще пришла в голову. У нормального менеджера не должно возникать мысли "а что так можно было?", когда видит, что конкурент получает преимущество благодаря внедрению какой-то технологической новинки.
Никто и не говорит о том, что менеджер должен для своего развития учить Турбо-Паскаль и установку винды. Но выяснить, какими средствами можно внедрить электронный документооборот в компании, или какие есть новые решения по автоматизации склада, это вполне себе достойная задача для профильного руководителя. Причем выяснить настолько, чтобы поставить конкретные цели и задачи своим специалистам и проконтролировать их выполнение.
На одни переговоры и формулировки задач/требований для ИТ-подрядчиков может уйти столько времени топов компании, на которые можно нанять небольшую, но свою команду разработки.
Это особенность советского менталитета, иметь все свое. Свою дачу, свой огород, свою лодку. Но на практике оказывается, что затраты на владение имуществом превышают плату за его временное пользование.
Что вы будете делать с командой разработки после того как проект закончится? Или вложите вы в них деньги, обучите, а они потом свалят к тем же ИТ-подрядчикам?
Что вы будете делать с командой разработки после того как проект закончится? Или вложите вы в них деньги, обучите, а они потом свалят к тем же ИТ-подрядчикам?
Да как-то не заканчиваются проекты. Аппетит приходит во время еды. Раньше бизнес не то, чтобы не хотел, а просто не понимало, «а что, так можно было». Как только автоматизировали что-то одно, тут же появляется масса идей, что надо разрабатывать далее.
Для развивающегося бизнеса (в смысле не в состоянии стагнации) проекты не заканчиваются. Нет состояния "всё, нам больше ничего автоматизировать не нужно, всё идеально", даже без учёта постоянных изменения требований и рекомендаций регуляторов. Естественно, содержание команды всего из двух взаимозаменяемых специалистов (двух — для минимизации рисков "попал под троллейбус"), подходит не каждому даже среднему бизнесу, не говоря о малых.
Del
Я в одной мелкой неайтишной фирме работал «летним программистом» в каждые университетские каникулы :-)
Для программиста на полную ставку у них работы не было, а в таком режиме — девять месяцев записывать возникающие задачи на бумажку, и потом за три месяца их все решить — получалась оптимальная нагрузка.
Теперь та фирма уже выросла и обзавелась постоянным программистом. Одним. Если он попадёт под троллейбус — компания погорюет, но бизнес не рухнет: начинался он вообще без айти, через телефоны и факсы.
С «айтишниками по вызову» они экспериментировали, но те оказались слишком накладными: чтобы за полчаса починить проблему, наёмному консультанту нужен час на дорогу, час на объяснение проблемы, и потом час на дорогу обратно, всё это за счёт заказчика.
Для программиста на полную ставку у них работы не было, а в таком режиме — девять месяцев записывать возникающие задачи на бумажку, и потом за три месяца их все решить — получалась оптимальная нагрузка.
Теперь та фирма уже выросла и обзавелась постоянным программистом. Одним. Если он попадёт под троллейбус — компания погорюет, но бизнес не рухнет: начинался он вообще без айти, через телефоны и факсы.
С «айтишниками по вызову» они экспериментировали, но те оказались слишком накладными: чтобы за полчаса починить проблему, наёмному консультанту нужен час на дорогу, час на объяснение проблемы, и потом час на дорогу обратно, всё это за счёт заказчика.
Что вы будете делать с командой разработки после того как проект закончится?
А что такое «проект закончился»? Проект по внедрению учетной системы обычно заканчивается в двух случаях — если от неё отказались и внедряют другую, либо если развитие бизнеса прекратилось. Если есть своя команда разработки, то первое обычно не происходит. А если произошло второе, то вопрос, что там будет с командой разработки, далеко не главная проблема для руководства компании.
Откуда вы черпаете информацию о вечных проектах?
Они такие обычно и есть, странно, что у вас какой-то другой опыт. Естественно, я не имею в виду внедрение 1С: УТП для SOHO, а что-то более крупное, предполагающее бизнес-анализ и кастомизацию.
Все проекты завершаются либо в установленный срок, либо завершаются вне установленного срока, но всегда завершаются. Вы явно что-то путаете.
Не путаю. Если вы имеете в виду проект как договор и техническое задание в папочке с подписями, то да, конкретно у этой штуки есть свой определенный срок жизни. Если мы говорим о проекте по внедрению учетной системы, то он состоит из кучи таких папочек, и после завершения одной появляется следующая, пока работает система или идет бизнес. Первоначальное внедрение переходит в эксплуатацию/сопровождение, периодически появляются крупные задачи по внедрению какого-то нового функционала или по миграции на новые версии и т.д.
Про книжки всё вообще прекрасно. Особенно когда мелкий бизнесмен читает про гигантов индустрии. Самый любимый раздел про зарплату работников, производительность труда и мотивацию.
Спасибо за статью. Кстати с SAPом ни разу не лучше, даже еще хуже, потому что в десять раз дороже и потом никто не признается, что спустил миллионы долларов на суррогат. Проще суррогатно написать, что проект успешен.
+очень много.
Зачастую намного хуже. Это поразительно, но в том числе и с технической точки зрения. Техподдержка просто посылает, несмотря на явные баги на стороне SAP'а.
По итогу при разборе полетов внезапно появляются термины вроде «чёрный лебедь». Дескать не предпологали такого развития ситуации, не было объективных средств контроля позволяющих обнаружить проблему в зачаточной стадии.
Да и вообще это у Вас всё было неправильно, а наш SAP правильный! Best practices же!!! Хотя по факту недостатков в системе очень и очень много. Зачастую на многих кейсах даже не стоит связываться с SAP. Сама задача предполагает либо другую систему автоматизации, либо самостоятельную разработку. Только понимают это очень и очень поздно. В конце начинается круговая порука и попытки спасти своё детище от надругательства. Что ещё сильнее усугбляет сложившуюся ситуацию.
В результате цифровая трансформация превращается в обновление версии SAP'а без изменений в бизнес-процессах, без по настоящему новых технологий и подходов. ИТ подразделение отъедает ещё больше ресурсов, чем ранее, доходы компании падают.
Зачастую намного хуже. Это поразительно, но в том числе и с технической точки зрения. Техподдержка просто посылает, несмотря на явные баги на стороне SAP'а.
По итогу при разборе полетов внезапно появляются термины вроде «чёрный лебедь». Дескать не предпологали такого развития ситуации, не было объективных средств контроля позволяющих обнаружить проблему в зачаточной стадии.
Да и вообще это у Вас всё было неправильно, а наш SAP правильный! Best practices же!!! Хотя по факту недостатков в системе очень и очень много. Зачастую на многих кейсах даже не стоит связываться с SAP. Сама задача предполагает либо другую систему автоматизации, либо самостоятельную разработку. Только понимают это очень и очень поздно. В конце начинается круговая порука и попытки спасти своё детище от надругательства. Что ещё сильнее усугбляет сложившуюся ситуацию.
В результате цифровая трансформация превращается в обновление версии SAP'а без изменений в бизнес-процессах, без по настоящему новых технологий и подходов. ИТ подразделение отъедает ещё больше ресурсов, чем ранее, доходы компании падают.
И как наиболее заметное проявление суррогатизма — любовь к модным словечкам.
Ну и да, тов. Белокаменцева я угадываю по стилю, не заглядывая в профиль автора:)
По словам автора статьи
Бизнес не любит: Реализовывать конкретные задачи
Бизнес любит: Ставить абстрактные задачи
Другими словами по вашему бизнес — это лентяй, который любит мечтать, но не любит сам работать, что бы воплотить свои мечты в жизнь.
Под работай в данном случае имеется в виду:
— проанализировать/найти/выбрать конкретный способ реализации своих мечт, потом
— проанализировать/найти/выбрать/нанять/заключить договор с конкретным исполнителем, потом
— проанализировать/составить план по срокам и качеству этапов работ выполненных исполнителем, потом
— организовать условия для работы исполнителя на своей территории, потом
— контролировать сроки и качество этапов работ выполненных исполнителем в соответствии с планом и в случае проблем незамедлительно принимать меры, потом
— проанализировать/принять/оплатить работу исполнителя, потом
— использовать/поддерживать реализованную мечту, потом
— анализировать/оценивать эффективность от реализованной мечты в реальности и той, что ставилась в самом начале.
После каждого пункта у меня стоит слово «потом», которое можно интерпретировать как «после чего», но те, кто в теме, думаю воспринимают его в другом смысле.
Большинство руководителей бизнесов, особенно государсвенных предприятий, любят мечтать — но не любят потеть.
Бизнес не любит: Реализовывать конкретные задачи
Бизнес любит: Ставить абстрактные задачи
Другими словами по вашему бизнес — это лентяй, который любит мечтать, но не любит сам работать, что бы воплотить свои мечты в жизнь.
Под работай в данном случае имеется в виду:
— проанализировать/найти/выбрать конкретный способ реализации своих мечт, потом
— проанализировать/найти/выбрать/нанять/заключить договор с конкретным исполнителем, потом
— проанализировать/составить план по срокам и качеству этапов работ выполненных исполнителем, потом
— организовать условия для работы исполнителя на своей территории, потом
— контролировать сроки и качество этапов работ выполненных исполнителем в соответствии с планом и в случае проблем незамедлительно принимать меры, потом
— проанализировать/принять/оплатить работу исполнителя, потом
— использовать/поддерживать реализованную мечту, потом
— анализировать/оценивать эффективность от реализованной мечты в реальности и той, что ставилась в самом начале.
После каждого пункта у меня стоит слово «потом», которое можно интерпретировать как «после чего», но те, кто в теме, думаю воспринимают его в другом смысле.
Большинство руководителей бизнесов, особенно государсвенных предприятий, любят мечтать — но не любят потеть.
«Так пропадают программисты на заводах… и… продолжают мечтать, слава Богу». Сколько работал, меня считали странным только за то, что я умею мечтать. Причем, если бы меня считали странным другие люди, я бы счел это нормальным, но нет, меня считали странным коллеги.
Это называется культ Карго. Вот смотрит руководитель: люди бормочут в микрофоны и самолёты прилетают. И думает, пусть мои сотрудники тоже в палочки бормочут, тоже наверное самолёты будут прилетать.
В палочки бормочут — это лайт версия. А большинство строят самолеты…
habrastorage.org/storage1/f3aa6ba3/3b986cea/836df5db/596c49be.jpg
И удивляются — почему не летают? :)))
habrastorage.org/storage1/f3aa6ba3/3b986cea/836df5db/596c49be.jpg
И удивляются — почему не летают? :)))
Мне кажется, что во втором списке «бизнес любит» все пункты ошибочные. :))
Если бы бизнес любил — он бы платил за пункты именно из второго списка. Но это не так.
Успешные проекты есть. Действительно успешные. Их не много, но есть. Некоторые из этих успешных проектов даже с использованием 1С. :)))
А то, что успешных проектов мало — так руководство в этом не очень заинтересовано.
Тут ведь дело не в том, чтобы рассуждать — чего мы хотим. А в том, чтобы действительно этого хотеть и действовать в этом направлении. Если директор «суррогат» — он будет много говорить о вещах из списка 2, но делать вещи из списка 1. И все остальные сотрудники тоже.
Так что не надо рассуждать о мифическом «бизнесе». Есть вполне реальные люди, с именами и фамилиями, которые принимают решения. И они в большинстве своем хотят вещей из списка 1, так как только в этом случае будут находиться в зоне комфорта.
Если бы бизнес любил — он бы платил за пункты именно из второго списка. Но это не так.
Успешные проекты есть. Действительно успешные. Их не много, но есть. Некоторые из этих успешных проектов даже с использованием 1С. :)))
А то, что успешных проектов мало — так руководство в этом не очень заинтересовано.
Тут ведь дело не в том, чтобы рассуждать — чего мы хотим. А в том, чтобы действительно этого хотеть и действовать в этом направлении. Если директор «суррогат» — он будет много говорить о вещах из списка 2, но делать вещи из списка 1. И все остальные сотрудники тоже.
Так что не надо рассуждать о мифическом «бизнесе». Есть вполне реальные люди, с именами и фамилиями, которые принимают решения. И они в большинстве своем хотят вещей из списка 1, так как только в этом случае будут находиться в зоне комфорта.
Это был первый этап формализма – подмена цели перечнем задач.
Как достичь цели, не выполняя задачи?
А они один построили. Суррогат? Ясен пень.
А что по-вашему будет лучше? Не строить ни один?
Когда я был ИТ-директором
Пробуйте делать без ТЗ, без требований и бумажек.
А, ну понятно. Если вы начальник — да, можете делать без ТЗ. Потому что вы и так в курсе всех изменений. Потому что заказчик у вас один, сотрудники компании, и они к вам и так идут с любыми доработками, то есть нет убытков от ситуации "сделайте мне в 2 раза больше за те же деньги". И потому что конкретно в вашей компании это нормально. Но для большинства программистов это вредный совет.
Вы имеете в виду какую-то свою ситуацию, только непонятно какую.
Дело не в том, что задачи не нужны, дело в том, что после формулировок задач о целях часто забывают, целями становится формальное выполнение задачи. Грубо, цель: уменьшить время обслуживания клиента, одна из задач — разбить сбор полного пакета документов с него на два этапа — минимально необходимый для предварительного предложения и остальные. Разбили, задача выполнена, но оказалось, что время увеличилось, поскольку:
— исполнители задачи не подумали о том, что во время ожидания предварительного решения можно и нужно переключиться на другого клиента, а не смотреть 5-10 минут на «ждите»
— у 50% клиентов и так только минимально необходимый комплект документов и по ним сразу можно принимать полное решение, не ожидая сообщения о предварительном решении, с тем чтобы отправить вторую форму пустой.
-
— исполнители задачи не подумали о том, что во время ожидания предварительного решения можно и нужно переключиться на другого клиента, а не смотреть 5-10 минут на «ждите»
— у 50% клиентов и так только минимально необходимый комплект документов и по ним сразу можно принимать полное решение, не ожидая сообщения о предварительном решении, с тем чтобы отправить вторую форму пустой.
-
Ага, теперь понятнее. Но я так понимаю, в этом случае неважно, на словах решили разбить или письменно. В обоих случаях можно отнестись формально «ты сказал мне разбить — я разбил». То есть дело не в наличии ТЗ, а в том, что надо для любой задачи обозначать цель, и проверять ее после реализации, возможно в виде отдельной задачи, и по результатам список задач корректировать. Это подразумевает участие лиц, которые могут решать, как тратить время работников — или начальников, или самих работников с большой свободой действий.
Не важно, да, в целом, но подмена целей задачами как раз признак (или этап) формализма, не важно письменного или устного.
Это подразумевает вовлеченность и мотивированность исполнителей в достижении цели, в не в решении технических задач. При большом количестве формализаций (форма не важна в целом, но обычно где-то письменная всё равно присутствует) легко получить ситуацию, когда даже непосредственный постановщик технических задач непосредственным исполнителям (условный техлид в команде разработки) уже ничего не знает о целях, фокусируясь на технических задачах.
Посмею заметить, что за все пункты во втором списке надо платить деньгами.
А ещё собственник или управленец перед обращением к специалистам должен:
Кто выполняет эти пункты, у того всё хорошо (в большинстве случаев). А если нехорошо, то тогда спрашиваем с подрядчиков согласно требований там, где они расходятся с реальностью.
Разумеется, нужно не стесняться и перед началом проекта закрепить требования к продукту или услуге. Эдакое QA.
А ещё собственник или управленец перед обращением к специалистам должен:
- уметь формулировать требования к услуге и продукту, которую заказывает,
- понимать зачем это нужно в его бизнесе
- понимать какие ресурсы нужны для содержания приобретенного продукта
- следовать рекомендациям специалистов, к которым обратился
- быть готовым менять бизнес-процессы в компании
Кто выполняет эти пункты, у того всё хорошо (в большинстве случаев). А если нехорошо, то тогда спрашиваем с подрядчиков согласно требований там, где они расходятся с реальностью.
Разумеется, нужно не стесняться и перед началом проекта закрепить требования к продукту или услуге. Эдакое QA.
Чувствуется, что автор вначале придумал интересный ему концепт, а потом начал подгонять под него реальность. Этакая общая натянутость и, временами, логические противоречия присутствуют.
Кстати говоря, в словосочетании «бизнес хочет/любит/не любит» что именно подразумевается под словом «бизнес»?
Суррогат – это когда сделали не то, что просили. Или не так, как просили. Или не сделали то, что просили. Или сделали, когда не просили.Иногда бывает еще хуже. Когда сделали именно то, что просили.
Кстати говоря, в словосочетании «бизнес хочет/любит/не любит» что именно подразумевается под словом «бизнес»?
В статье какой-то юношеский максимализм.
У бизнеса есть N миллионов рублей на имплементацию каких-то фич, потому что «конкуренты сделали это же за N*2 (или даже N/2) миллионов рублей», потому что ойти — это круто и современно, потому что облачные технологии, виртуализация, биткоин, мобильность сотрудников.
Именно этим живут все крупные интеграторы. Инфраструктура ради инфраструктуры — но у этих людей есть бабки на enterprise exchange cal, citrix+rds на всех сотрудников, сфб кал по числу реальных мобильных устройств и так далее. 50, 100, 300 тысяч рублей на рабочее место в год — да как нехрен.
А те, кто не придерживаются этих принципов — те работают за копейки.
У бизнеса есть N миллионов рублей на имплементацию каких-то фич, потому что «конкуренты сделали это же за N*2 (или даже N/2) миллионов рублей», потому что ойти — это круто и современно, потому что облачные технологии, виртуализация, биткоин, мобильность сотрудников.
Именно этим живут все крупные интеграторы. Инфраструктура ради инфраструктуры — но у этих людей есть бабки на enterprise exchange cal, citrix+rds на всех сотрудников, сфб кал по числу реальных мобильных устройств и так далее. 50, 100, 300 тысяч рублей на рабочее место в год — да как нехрен.
А те, кто не придерживаются этих принципов — те работают за копейки.
В статье какой-то юношеский максимализм.
Наоборот, старческое брюзжание.
Юноши верят, что it-технологии помогают бизнесу. И не хотят ничего слушать, если кто-то говорит, что это не так.
Потому что рушится иллюзия о своей принадлежности к чему-то великому. Больно думать, что я, молодой парень, выбравший профессию программиста, на самом деле — втюхиватель бессмысленных технологий, и сижу на пороховой бочке. Когда поймут, что толку от меня и технологий нет, выгонят ссаными тряпками.
Нафиг об этом думать, так ведь и в депрессию можно впасть. Лучше просто делать, и все. Как говорят, делай, что должен, и будь, что будет.
А когда пройдет 10, 20, 30 лет, и окажется, что не принес никакой пользы, поздно будет что-то менять. Можно будет оправдываться, типа меня обманули, это Google, Mail и Yandex виноваты, заманили в программисты, сказали что я мир менять буду, а сделали из меня никому не нужную печатную машинку. Еще и нажились на мне, продавая суррогаты.
Не знаю как кому, но мне удивительно.
Внедрял на фирме 1С УПП, с ее приходом стало прозрачнее планирование, закупки, остаток на складе и проч. Короче доволен, гораздо лучше, чем в Экселе было до того. Правда 1С программиста не нанимали, изредка обращаемся за поддержкой в контору.
Был «Представителем руководства по СМК», правда требование было в основном чтобы «было всё по новому оставаясь всё по старому» так что в итоге пришлось ограничиться «меньшим злом».
Составление ТЗ на бумаге — если это не написать, то куча специалистов изо дня в день будут тянуть одеяло требований на себя и проект никогда не начнется, а начавшись, не закончится. А когда закончится, то выяснится, что оно никому не нужно, и все будут говорить «я же говорил, что нужно делать по другому!».
Короче ИМХО статья в стиле «Баба Яга против».
Внедрял на фирме 1С УПП, с ее приходом стало прозрачнее планирование, закупки, остаток на складе и проч. Короче доволен, гораздо лучше, чем в Экселе было до того. Правда 1С программиста не нанимали, изредка обращаемся за поддержкой в контору.
Был «Представителем руководства по СМК», правда требование было в основном чтобы «было всё по новому оставаясь всё по старому» так что в итоге пришлось ограничиться «меньшим злом».
Составление ТЗ на бумаге — если это не написать, то куча специалистов изо дня в день будут тянуть одеяло требований на себя и проект никогда не начнется, а начавшись, не закончится. А когда закончится, то выяснится, что оно никому не нужно, и все будут говорить «я же говорил, что нужно делать по другому!».
Короче ИМХО статья в стиле «Баба Яга против».
«Пробуйте делать без ТЗ, без требований и бумажек. Пробуйте достичь цели.»
мне как раз ТЗ помогает достичь цели, потому что без этого текста с картинками-диаграммами, как то быстро забывается куда надо идти и какой путь следует выбирать.
формализм нужен, но если документ сделали, то надо его актуализировать постоянно и постоянно с ним сверяться.
с круговой порукой согласен — люди когда не понимают, они бояться признаться что не понимают и ленятся разобраться.
постепенность — она во всё есть, надо о цели не забывать, опять же — сверяться с документом :)
мне как раз ТЗ помогает достичь цели, потому что без этого текста с картинками-диаграммами, как то быстро забывается куда надо идти и какой путь следует выбирать.
формализм нужен, но если документ сделали, то надо его актуализировать постоянно и постоянно с ним сверяться.
с круговой порукой согласен — люди когда не понимают, они бояться признаться что не понимают и ленятся разобраться.
постепенность — она во всё есть, надо о цели не забывать, опять же — сверяться с документом :)
Наличие ТЗ обычно предполагает уже чётко выбранный технический путь достижения цели. Собственно сама цель в ТЗ может быть и не указана. ТЗ — это вроде маршрута "поверните налево, поверните направо — вы прибыли на место назначения", в котором место назначения вообще может быть и не указано.
мне как исполнителю большего не надо :) моя цель что бы при пинке с силой N по реализованному чёрному ящику звучал звук У определённой тональности и громкости, цели вызывать в слушателях определённых эмоций я не ставлю, это цель интегратора и владельца чёрного ящика, моё дело этот ящик сколотить и покрасить.
Есть мнение, что подобная позиция исполнителей снижает эффективность достижения целей. :)
есть мнение что руководство и аналитики занимаются целеполаганием, а не исполнители.
Целеполаганием, да. Но есть мнение :), что эффективнее исполнители работают, когда понимают что и зачем они делают. Даже чисто психологически, если, конечно, им интересны эти цели. Одно дело решить задачу типа: "уменьшить время отклика страницы до N ms" и другое "увеличить конверсию путём уменьшения отклика". Это не говоря о возможности, что исполнители предложат лучшее решение по достижению тех же целей.
тем не менее ТЗ полезный документ, дать возможность познакомиться с целями проекта, то будет не лишним, ок :)
UFO just landed and posted this here
обожаю этот документ, там вечно хрень полная написана и её ни кто не хочет менять. Я один раз даже из-за этого уволился.
Итальянская забастовка это когда сотрудники динамят, как бы ни каким формализмом и KPI человека не заставить работать по совести, поэтому относиться к документам как инструментам гарантии 100% качества это не разумно.
Тем не менее документы описывают рамки, я когда техподдержкой занимался, по прочтению договора узнал много нового и половину заявок стал заворачивать как не относящиеся к делу, потому что завод (и не только) обнаглел и тупо сел на шею.
Моё мнение документы, очень важная штука как ориентир. Для меня, качество моей работы без них страдает.
Итальянская забастовка это когда сотрудники динамят, как бы ни каким формализмом и KPI человека не заставить работать по совести, поэтому относиться к документам как инструментам гарантии 100% качества это не разумно.
Тем не менее документы описывают рамки, я когда техподдержкой занимался, по прочтению договора узнал много нового и половину заявок стал заворачивать как не относящиеся к делу, потому что завод (и не только) обнаглел и тупо сел на шею.
Моё мнение документы, очень важная штука как ориентир. Для меня, качество моей работы без них страдает.
UFO just landed and posted this here
ТЗ переписывается и согласуется, а должностная инструкция написана 100 лет назад и больше не меняется, потому что должностная инструкция это отдел кадров, а ТЗ это непосредственный заказчик и непосредственный исполнитель. Разные отношения.
я завод не динами, это завод от меня требовал лишнего, завод требовал выполнения работ которые в техподдержку не входят, требовал работ выходящих за рамки договора.
всегда можно передёргивать, а можно не передёргивать. зависит от воли и исполнителей и руководителей.
я завод не динами, это завод от меня требовал лишнего, завод требовал выполнения работ которые в техподдержку не входят, требовал работ выходящих за рамки договора.
всегда можно передёргивать, а можно не передёргивать. зависит от воли и исполнителей и руководителей.
Мало того, Джим Коллинз описывает, что все великие компании отличались тем, что объединяли всех своих сотрудников общей идеологией, которая позволяла им работать сообща. Понимаете? Все! Чувствуется присутствие цели?
Остальные же компании оказались менее жизнеспособны или долговечны, не смотря на то, что в какой-то период достигали очень хороших показателей. Короче, узкая ответственность и отсутствие видения общей картины — путь к посредственности.
Остальные же компании оказались менее жизнеспособны или долговечны, не смотря на то, что в какой-то период достигали очень хороших показателей. Короче, узкая ответственность и отсутствие видения общей картины — путь к посредственности.
Блин. Диалоги программиста и пользователя прям до слез. Вы за мной следите? У меня таких диалогов 3-4 на день. 80% отлуп наглым пользователям )))
Среднестатистический мужчина не любит:
1. Заниматься в спортзале.
И, как ни странно, среднестатистический мужчина любит
1. Красивое мускулистое тело без капли лишнего жира.
Хотел было написать простыню текста с разбором ошибок в тексте, но, надеюсь, текст выше покажет в чем главная ошибка автора.
Разумеется, франчи никак не ангелы, но рассказывать что виноваты в провалах внедрений только они, а бизнес прям весь белый и пушистый — признак полного непонимания ситуации.
1. Заниматься в спортзале.
И, как ни странно, среднестатистический мужчина любит
1. Красивое мускулистое тело без капли лишнего жира.
Хотел было написать простыню текста с разбором ошибок в тексте, но, надеюсь, текст выше покажет в чем главная ошибка автора.
Разумеется, франчи никак не ангелы, но рассказывать что виноваты в провалах внедрений только они, а бизнес прям весь белый и пушистый — признак полного непонимания ситуации.
Насколько могу судить, бизнес просто не понимает, что и как должно быть, а следует принципу «а как там у Иваныча».
А иногда и «как там у Билли Гейтса». Они ж книжку почитали…
Вообще это одна из серьёзнейших проблем внедрения: отсутствие понимания у бизнеса того, что же им действительно нужно, выраженного в четких транслируемых понятиях.
Почему, кстати, внедрение бухгалтерского учёта и расчета зарплаты проходит не в пример легче, чем управленческого: там цели и задачи определены гораздо лучше и четче.
Вообще это одна из серьёзнейших проблем внедрения: отсутствие понимания у бизнеса того, что же им действительно нужно, выраженного в четких транслируемых понятиях.
Почему, кстати, внедрение бухгалтерского учёта и расчета зарплаты проходит не в пример легче, чем управленческого: там цели и задачи определены гораздо лучше и четче.
В общем и в целом, бизнес не компетентен в вопросах внедрения ИТ-продуктов. Был бы компетентен ему не нужны были бы интеграторы и прочие внедряторы в общем случае. Им платят в основном не за работу "могу копать, могу не копать", и даже не за технические знания конкретных продуктов (технических спецов относительно не сложно привлечь, даже временно), а именно за предоставление решения "под ключ", начиная с процессов постановок целей внедрения и сбора требований.
Но требования-то эти надо четко сформулировать, не так ли? И сделать это должен бизнес. А с этим нередко большие проблемы.
Кроме того, часто случается так, что эффективное решение «под ключ» требует перестройки бизнес-процессов в той или иной степени. А каждый ли бизнес пойдёт на это? По моему опыту — очень даже не каждый.
Короче: если в процессе внедрения бизнес занимает позицию «за все уплочено, делать я ничего не буду», то шансы на успешную реализацию сколь-нибудь сложного проекта по внедрению управленческого учёта минимальны.
Кроме того, часто случается так, что эффективное решение «под ключ» требует перестройки бизнес-процессов в той или иной степени. А каждый ли бизнес пойдёт на это? По моему опыту — очень даже не каждый.
Короче: если в процессе внедрения бизнес занимает позицию «за все уплочено, делать я ничего не буду», то шансы на успешную реализацию сколь-нибудь сложного проекта по внедрению управленческого учёта минимальны.
Чётко сформулировать требования к ИТ-продукту может только компетентное в ИТ лицо. И даже компетентное в ИТ в целом, но не в процессах внедрения сторонними силами, какие-то вещи может считать очевидными и даже не требующими отдельных строчек в калькуляциях, типа организации резервного копирования, просто must have. Или вот лично встречался с ситуацией со стороны заказчика, когда в проекте на несколько лет был обозначен целевой браузер Хром, но в процессе внедрения он много раз успел обновиться и минимум одно обновление пришло с ломкой BC (что-то там с маской в теге input ) — внедрятор предложил откатиться и зафиксировать версию Хрома на рабочих станциях персонала. С его точки зрения адаптация продукта под новое поведение Хрома была доработкой, поскольку ту функциональность уже приняли, с нашей — багфикс, поскольку в базу значение записывалось как пришло из браузера, а в требованиях чётко был описан формат, но форматирование они сделали только на фронте, ввод и вывод. С его — фиксация версии обычная адаптация окружения под продукт, с нашей — предложение сделать во всей нашей сети потенциальную дырищу в безопасности. Не помню, чем дело закончилось, заплатили или нет, но копий было поломано немало.
Товарищ Иван Б. уже здесь, правильно нужно охватывать так сказать правильными мыслями как можно большую часть общества, прогрессивного общества.
UFO just landed and posted this here
Суррогатизм он наверное в большинстве торгово-производственных компаний обитает. По другому бизнес не умеет. Гонка за быстрой прибылью и жадность собственников превращает ит в суррогат.
Моя практика показывает, что большинство бизнесменов не только за прибылью гонятся, но и думают о стратегическом развитии, об эффективности и успешной бизнес-модели.
Но они одиноки. Сами все сделать не могут, а помочь некому. Одни засранцы вокруг, жулики и тунеядцы.
Но они одиноки. Сами все сделать не могут, а помочь некому. Одни засранцы вокруг, жулики и тунеядцы.
Может просто у них в приоритетах не краткосрочные перспективы получения прибыли, а долгосрочные? Про благотворительность и социальную ответственность вы не упомянули ведь. Да и те нередко рассматриваются лишь как долгосрочная инвестиция, хоть как-то минимизирующая внимания со стороны государства. "Юкос" это не спасло, но лично я уверен, что рассматривались эти вложения именно в таком ключе.
«Основная задача персональных вычислений — формализация профессиональных знаний — выполняется, как правило, полностью самостоятельно непрограммирующим профессионалом или при минимальной технической поддержке программиста, который в этом случае имеет возможность включаться в процесс формализации знаний только на инструментальном уровне, оставляя наиболее трудную для его понимания содержательную часть задачи специалисту в данной предметной области.» (ТЕХНОЛОГИЯ АВТОФОРМАЛИЗАЦИИ ПРОФЕССИОНАЛЬНЫХ ЗНАНИЙ Г.Р.Громов.)
Дело в том, что разработчик на платформе 1С — это и есть «непрограммирующий профессионал», а, следовательно, он обязан понимать содержательную часть задачи предметной области и решать основную задачу персональных вычислений. Противоречие возникает в тех случаях, когда специалист 1С забывает о том, что «формализм» это целиком его зона ответственности.
Методология учета, консультации и обучение пользователей также относятся к компетенции специалистов 1С. Понятно, что «истина всегда конкретна» и каждое внедрение ПО требует индивидуального подхода к клиенту, но тем не менее, всегда полезно соблюдать базовые принципы. Консультации и обучение, — почасовые услуги без ТЗ. Настройка типового решения 1С, — почасовые услуги без ТЗ. При разработке отраслевого решения на платформе 1С, необходимо соблюдать официальный перечень требований 1С, включающий требования к документации.
К сожалению, иногда происходит подмена понятий — логическая ошибка, заключающаяся в выдаче какого-либо программного продукта за решение, каким он заведомо не является, и в использовании несоответствующих контексту задачи определений.
Суррогат и формализм — это подмена понятий. Сам термин «формализм» не несет негативного смысла, даже напротив, в контексте программной разработки формализм напрямую связан с формальной логикой и дедукцией, для которой характерны: непротиворечивость, полнота, независимость, разрешимость. Формальное описание предметной области весьма ценно. В какой форме оптимально фиксировать формализованные знания это отдельный вопрос. Кому-то нравится спецификация через тестирование, кому-то списки требований в екселе, кто-то зачарован диаграммами UML простор тут большой. К большому сожалению, многие ограничиваются заметками в msword, в запущенных случаях по ГОСТ-34.
Дело в том, что разработчик на платформе 1С — это и есть «непрограммирующий профессионал», а, следовательно, он обязан понимать содержательную часть задачи предметной области и решать основную задачу персональных вычислений. Противоречие возникает в тех случаях, когда специалист 1С забывает о том, что «формализм» это целиком его зона ответственности.
Методология учета, консультации и обучение пользователей также относятся к компетенции специалистов 1С. Понятно, что «истина всегда конкретна» и каждое внедрение ПО требует индивидуального подхода к клиенту, но тем не менее, всегда полезно соблюдать базовые принципы. Консультации и обучение, — почасовые услуги без ТЗ. Настройка типового решения 1С, — почасовые услуги без ТЗ. При разработке отраслевого решения на платформе 1С, необходимо соблюдать официальный перечень требований 1С, включающий требования к документации.
К сожалению, иногда происходит подмена понятий — логическая ошибка, заключающаяся в выдаче какого-либо программного продукта за решение, каким он заведомо не является, и в использовании несоответствующих контексту задачи определений.
Суррогат и формализм — это подмена понятий. Сам термин «формализм» не несет негативного смысла, даже напротив, в контексте программной разработки формализм напрямую связан с формальной логикой и дедукцией, для которой характерны: непротиворечивость, полнота, независимость, разрешимость. Формальное описание предметной области весьма ценно. В какой форме оптимально фиксировать формализованные знания это отдельный вопрос. Кому-то нравится спецификация через тестирование, кому-то списки требований в екселе, кто-то зачарован диаграммами UML простор тут большой. К большому сожалению, многие ограничиваются заметками в msword, в запущенных случаях по ГОСТ-34.
Термин "формализм" всё же содержит негативные коннотации в русском языке, например
ФОРМАЛИЗМ — приверженность внешним формам в ущерб содержанию. В области человеческих отношений проявляется в неукоснительном следовании правилам этикета, обрядности, ритуала даже в тех случаях, когда жизненная ситуация делает это нелепым и бессмысленным..."
Словарь терминов и понятий по обществознанию. Автор-составитель А.М. Лопухов. 7-е изд. переб. и доп. М., 2013, с. 441.
Любит, не любит — в конечном итоге все сводится к тому, что конкретный бизнесмен может и чего он не может.
По факту — да, потому что только он сам может что-то изменить. Это вынужденная реальность. Те, кто вроде по призванию должен делать мир лучше, производит суррогаты, и ничего больше не умеет.
Отсюда такая популярность книг, тренингов и семинаров по изменениям в бизнесе. Потому что в живом мире — голяк.
Отсюда такая популярность книг, тренингов и семинаров по изменениям в бизнесе. Потому что в живом мире — голяк.
Бизнес не любит
— расходы
— расходы
— расходы
— расходы
При этом, бизнес любит
— доходы
— экономию
— сокращение расходов
— оперативность сведений
Бизнес… во всей красе…
— расходы
— расходы
— расходы
— расходы
При этом, бизнес любит
— доходы
— экономию
— сокращение расходов
— оперативность сведений
Бизнес… во всей красе…
Не, вы не правы.
Бизнес обожает расходы, которые приводят к доходам. У бизнеса мозг так устроен — как у инвестора.
Придите к собственнику, скажите — я тут придумал штуку одну клевую, дай мне 1 млн рублей, я тебе через полгода 2 верну, ну и бизнес-модель получишь. Даст с радостью.
Только так внутри бизнеса, среди наемных работников, редко кто мыслит. Не могут проложить дорожку от расходов к доходам. Поэтому приходят за деньгами, имея в виду тупо расход.
Например, дайте 10 млн на автоматизацию. Что получу, спрашивает собственник. Систему, отвечают просители. А нахера она мне, спрашивает собственник. Ну, она затраты сократит, прибыль увеличит. Насколько, спрашивает собственник. Ну, не знаем мы, дяденьки из франча сказали, что сократит и увеличит.Как вы мне все надоели, говноеды вонючие Хорошо, запускайте процедуру, договор, требования, ТЗ, сроки, этапы.
Бизнес обожает расходы, которые приводят к доходам. У бизнеса мозг так устроен — как у инвестора.
Придите к собственнику, скажите — я тут придумал штуку одну клевую, дай мне 1 млн рублей, я тебе через полгода 2 верну, ну и бизнес-модель получишь. Даст с радостью.
Только так внутри бизнеса, среди наемных работников, редко кто мыслит. Не могут проложить дорожку от расходов к доходам. Поэтому приходят за деньгами, имея в виду тупо расход.
Например, дайте 10 млн на автоматизацию. Что получу, спрашивает собственник. Систему, отвечают просители. А нахера она мне, спрашивает собственник. Ну, она затраты сократит, прибыль увеличит. Насколько, спрашивает собственник. Ну, не знаем мы, дяденьки из франча сказали, что сократит и увеличит.
Вообще, вся статья — в первую очередь, наезд на отрасль 1С (как на франчей, так и на фикси), причем не особо скрытый. С первого же предложения ясно.
За франчей заступаться не буду — на их стороне не был. Хотя примерно их понимаю. У них у самих бизнес, и их интересует как раз то, что перечислено во втором списке, а точнее — прибыльность. Своя собственная прибыльность, а не того — кому они внедряют продукт. Далеко не многие понимают, что действительно выгодная стратегия — это WIN-WIN, когда все в выигрыше.
С другой стороны — в инете можно найти довольно много баек и комиксов от Web-дизайнеров про своеобразность работы с заказчиками. Байки эти на жизни основаны. Поработаешь с парой-тройкой таких без ТЗ, и формализмом заниматься поневоле захочется.
Второй момент постепенность, или рутина. Приведённых примеры диалогов — это скрытое манипулирование. Ещё бывает в другом ключе «ты же умный, ты суперпрограммист, ...» и т.д., т.е. заставляют делать свою работу. В целом, тут главное придерживаться принципа — «Программист это тот, кто делает инструменты, а не тот кто с ними работает». Сделал механизм (отчет/обработку/документ), описал, обучил как с ним работать, и всё, не более. В идеале, программисту должно быть СКУЧНО выполнять монотонную работу с использованием собственных инструментов. Конфликты подобного рода обычно до руководства не доходят (проверено, не раз отказывал), а если и доходят — начальство принимает сторону программиста. И даже если не принимает — можно из этого извлечь выгоду. В виде оправдательной причины «почему вот эта задача выполнена на неделю/месяц/квартал позже, чем запланировано.
Третье — круговая порука, ну тут см. выше про франчей. Про фикси — скажу так: у них есть начальство, и это не владелец бизнеса. И это начальство требует решения определённых задач. Конкретных задач. ИТ-руководство, более приближенное к владельцу бизнеса, также имеет определённые установки и цели, поставленные этим владельцем. И никакой круговой поруки тут нет. Тупо погоня за быстрыми деньгами (франчи) или за премией к зарплате (фикси).
(P.S.) Как Вы думаете, почему бизнес обращается к 1С? Как ни странно — это дёшево. При этом, ещё помогает удовлетворить похотливые услуги нашего государства в плане отчётности по налогам, статистике и т.п.
За франчей заступаться не буду — на их стороне не был. Хотя примерно их понимаю. У них у самих бизнес, и их интересует как раз то, что перечислено во втором списке, а точнее — прибыльность. Своя собственная прибыльность, а не того — кому они внедряют продукт. Далеко не многие понимают, что действительно выгодная стратегия — это WIN-WIN, когда все в выигрыше.
С другой стороны — в инете можно найти довольно много баек и комиксов от Web-дизайнеров про своеобразность работы с заказчиками. Байки эти на жизни основаны. Поработаешь с парой-тройкой таких без ТЗ, и формализмом заниматься поневоле захочется.
Второй момент постепенность, или рутина. Приведённых примеры диалогов — это скрытое манипулирование. Ещё бывает в другом ключе «ты же умный, ты суперпрограммист, ...» и т.д., т.е. заставляют делать свою работу. В целом, тут главное придерживаться принципа — «Программист это тот, кто делает инструменты, а не тот кто с ними работает». Сделал механизм (отчет/обработку/документ), описал, обучил как с ним работать, и всё, не более. В идеале, программисту должно быть СКУЧНО выполнять монотонную работу с использованием собственных инструментов. Конфликты подобного рода обычно до руководства не доходят (проверено, не раз отказывал), а если и доходят — начальство принимает сторону программиста. И даже если не принимает — можно из этого извлечь выгоду. В виде оправдательной причины «почему вот эта задача выполнена на неделю/месяц/квартал позже, чем запланировано.
Третье — круговая порука, ну тут см. выше про франчей. Про фикси — скажу так: у них есть начальство, и это не владелец бизнеса. И это начальство требует решения определённых задач. Конкретных задач. ИТ-руководство, более приближенное к владельцу бизнеса, также имеет определённые установки и цели, поставленные этим владельцем. И никакой круговой поруки тут нет. Тупо погоня за быстрыми деньгами (франчи) или за премией к зарплате (фикси).
(P.S.) Как Вы думаете, почему бизнес обращается к 1С? Как ни странно — это дёшево. При этом, ещё помогает удовлетворить похотливые услуги нашего государства в плане отчётности по налогам, статистике и т.п.
На мой взгляд все сказанное отлично подходит и к трейдингу. Брокеры, аналитики, консультанты наводняют суррогатами. Царит формализм, постепенность и круговая порука. В точку!
Разорвите круговую поруку, сделайте революцию… А сколько за это заплатят? Автор совершенно ничего на этот счёт не написал.
Sign up to leave a comment.
Суррогаты