1. 1С-Франчайзи, программистов 1С вообще, и почти все, что те делают;
2. веб-программистов и компании, создающие и продвигающие сайты, и все продукты их работы;
3. системы менеджмента качества и людей, которые занимаются их внедрением;
4. бухгалтеров и бух.учет;
5. экономистов со всеми их гигантскими экселевскими портянками;
6. внутренние проекты развития, на которые без слез уже смотреть невозможно;
7. Scrum и все эти доски, на которых неделями висят одни и те же стикеры;
8. ТОС, после внедрения которого дефицитов и неликвидов становится еще больше;
9. Контроллинг, который дает цифры позже, чем бух.учет;
10. KPI, адекватность которого приходится доказывать самому себе каждый раз, когда приносят эти цифры;
11. Системы мотивации, которые, как ни крути, «оклад+премия», хоть и названы модными словами, типа «грейд».
Продолжать можно до бесконечности. Никогда не задумывались, почему бизнес всего этого не любит? Или вообще не замечали, что бизнес этого не любит?
При этом, как ни странно, бизнес любит:
1. повышение прибыльности бизнеса за счет автоматизации;
2. увеличение количества лидов и рост оборота за счет правильного продвижения;
3. повышение качества процессов производства и бизнес-процессов;
4. полезный бухгалтерский учет, дающий простую и понятную картину бизнеса в цифрах по принципам двойной записи;
5. полезный управленческий учет, дающий своевременные цифры и прогнозы состояния компании;
6. эффективные проекты повышения эффективности, запущенные и выполненные внутри компании, с небольшим бюджетом и сохраненными в компании компетенциями;
7. повышение эффективности проектной или потоковой работы в 2-4 раза;
8. кратное увеличение оборотов и прибыли, снижение всех видов запасов, избавление от избыточных мощностей всех видов;
9. точную систему управления, своевременно реагирующую на отклонения и помогающую принимать правильные решения всем участникам процессов;
10. многогранную, понятную, правильно сходящуюся в 1-3 цифры систему оценки всех областей бизнеса, дающую оценку состояния дел за несколько минут без длительных совещаний и докладов;
11. четкую систему измерения и оценки человеческого труда, которая еще и выполняет функцию управления, позволяя разогнать половину ненужных менеджеров, которые любят «руками водить» (=«руководить»).
Чувствуете разницу? Или еще нет? Я специально сделал список один к одному, чтобы можно было сопоставить.
Чтобы еще сильнее вас запутать, добавлю п.12, общий для всех: бизнес очень любит читать книги разных гуру про все перечисленные темы, того же Гейтса, Деминга, Оно, Голдратта, Сазерленда и т.д.
Теперь, уверен, вы все поняли.
В книгах – оригинал, эталон. Как оно должно быть. Ради чего оно было придумано. Цель. Что должна давать автоматизация бизнесу. Как ускоряется работа над проектом в 4 раза. Как потери от брака сделать вероятностью, а не реальностью. Как управлять бизнесом, тратя на это 20 минут раз в месяц и читая один лист А4 с тремя цифрами. Как увеличить оборот в разы, просто покупая только то, что нужно. Кому ж такое не понравится? И люди авторитетные пишут, и на практике все проверено, и съездить посмотреть можно. Оригинал. Как Мона Лиза в Лувре, у которой всегда толпы китайцев и японцев.
Второй список – это мысленные проекции оригинала на конкретный бизнес. Руководитель прочитал, вдохновился, захотел так же, посмотрел на свой бизнес через призму оригинала, увидел очевидные преимущества от изменений, сформулировал цель.
И тут вступают в действие друзья из первого списка. Не знаю лучшего фразеологизма, который опишет первый список, чем «хотели как лучше, а получилось как всегда». Есть еще чуть менее подходящий – «не догоним, так хотя бы согреемся».
Есть, правда, и антипаттерн, приведу ключевую цитату: «Наша работа заключается в том, чтобы найти наиболее удобный, простой и красивый способ решения поставленной задачи, не потеряв по дороге смысл». Не буду судить, насколько они следуют своему лозунгу, но звучит красиво.
Все, хватит ходить вокруг да около, эта статья – про суррогаты и их производителей.
Суррогат – это когда сделали не то, что просили. Или не так, как просили. Или не сделали то, что просили. Или сделали, когда не просили.
Суррогаты – это самое страшное зло, происходящее сейчас с российским бизнесом и государственным управлением. Суррогаты – это лучший в мире киллер эффективности. Что особенно приятно, мы, программисты, на этот раз не в стороне – мы на самой оси зла.
У нас с вами не прямой диалог, и это замечательно. Вы не обязаны защищаться, нападать и оправдываться. Просто подумайте и посмотрите вокруг, вспомните свои проекты, автоматизированные компании, их руководителей. И постарайтесь вспомнить, о чем говорили на первых встречах.
Я когда-то был 1Сником. Начал работать в 2005 году, сразу с v8 и УПП, поэтому застал большой хайп автоматизации производственных предприятий, который был в 2005-2009 годах.
Всегда – всегда – заказчик хотел одного и того же, хоть и называл это разными словами. Снизить издержки, своевременно получать цифры, сократить персонал, планировать всё и вся, видеть эффективность людей, принимать управленческие решения на основе данных системы, бла-бла-бла.
И всегда – всегда – заказчик получал одно и то же. Заказчик всегда получал автоматизацию бух.учета, регл. расчет зарплаты, зачатки CRM, простецкий управленческий учет, инструкцию по работе с «Помощником планирования», кучу печатных форм на все случаи жизни, кучу кода и обновление релизов часов по 100 каждый (пока УПП не прекратили развивать), необходимость нанять программиста 1С (а лучше двух) и раздутый штат бухгалтеров, экономистов и прочих операторов, которые вместе с программистом 1С становятся придатками системы.
Нет, бывали, конечно, исключения. Я должен был написать эту фразу, чтобы смягчить формулировки. Но исключений не было.
Еще одна богатая суррогатами отрасль – это менеджмент качества. Наверняка слышали про «внедрение системы менеджмента качества в соответствии с международными стандартами ISO 9001». Это почти всегда – суррогат.
Здесь исключения уже бывают. Например, компании нужен сертификат ISO, чтобы участвовать в тендере. Тогда все честно – сертификат можно просто купить (это незаконно, конечно, но можно).
Но среди менеджеров еще не перевелись романтики, которые где-то прочитали, что стандарты ISO – это выжимка лучших практик менеджмента, внедрив которые в компании, можно серьезно увеличить ее конкурентные преимущества, повысить прозрачность процессов, сделать измеримыми результаты для всех потребителей, внешних и внутренних, заявить о себе на международном уровне, бла-бла-бла. Ничего не напоминает?
В результате внедрения стандарта ISO обычно не происходит ничего хорошего.
Самый лучший вариант, т.е. меньшее зло – когда создается маленький отдел, иногда из одного человека, который и занимается всеми этими бумажками, и проходит ресертификацию. Просто иногда подсовывает руководителям на подпись очередные отчеты об аудитах, карточки улучшений процессов, отчеты с показателями качества за квартал и т.д.
Вариант хуже – когда все эти бумажки реально встраиваются в жизненные процессы. Никто, в т.ч. внедренцы, не знают, зачем эти бумажки нужны в процессе. Но есть отмазка – это ж из стандарта ISO. А его разработчики так далеко, что и спросить не у кого.
К счастью, избавиться от внедренного стандарта ISO довольно легко, что некоторые уже делают. Просто выкидывают его на помойку и перестают проходить сертификацию.
Есть масса менее распространенных производителей суррогата. Сюда можно отнести большую часть бизнес-консультантов со всеми их ТОСами, Scrum’ами, Lean’ами и т.д.
Про сайтоделателей и упоминать не стоит. Достаточно вспомнить, зачем их приглашают – продажи увеличить.
Теперь – про то, как и почему суррогаты все-таки появляются. Должны же они каким-то законам подчиняться.
Производство суррогатов, как тренд, зиждется на трех китах: формализм, постепенность и круговая порука.
Главный, наверное, формализм, вы все о нем знаете. Это первый этап производства суррогата. Начинается с фразы «давайте теперь зафиксируем на бумаге». Так появляются разного рода требования, договоры, проекты, этапы, графики, сроки. Обычно в проектной документации не забывают упомянуть и цель проекта – те фантазии, которые заказчик на первой встрече говорил. Но как мы знаем из жизни, никто раздел «Цели» потом уже не перечитывает.
Главное – как можно быстрее перевести внимание на детали. Дать человеку вместо его целей иллюзию контроля – вот тебе этапы, графики, задачи, ты контролируй, мы тебе сдавать будем, назначь ответственных, пусть все проверяют, требования корректировать будем, бюджет увеличим, если понадобится.
Видите, что происходит? Банально – перенос фокуса внимания. Как часто пишут в оппозиционных СМИ, перевод внимания с реальных проблем на выдуманные. Создаем проблему, с которой надо много возиться, и человек увлеченно возится.
Например, с контролем сроков выполнения работ. Это ж излюбленное дело всех менеджеров – сроки контролировать. А когда речь о многомиллионном проекте, так и щеки надувать сам Бог велел – я занят важным делом, сроки контролирую.
На этом этапе цель проекта вообще пропадает из поля зрения. О ней уже никто не вспоминает. И чем дальше, тем меньше будут вспоминать.
Это был первый этап формализма – подмена цели перечнем задач. Отдельная, очень интересная тема – как вообще цели превращаются в задачи. На эту тему написано много книг, диссертации, методы (математические, статистические, модные менеджерские), и вроде как считается, что все это должны уметь.
А что на самом деле? Вот в среде 1С: Франчайзи, например. Приходя с проектом внедрения на предприятие, мы ведь заранее знаем, что там будет внедряться. Послушать цели проекта – это скорее формальность. Мы просто отметим галочками те подсистемы, которые на данном предприятии в приоритете. Ну и те, на которые можно заложить побольше часов из-за пристального внимания руководства предприятия, или (бывает) нездоровой любви к какому-то конкретному участку.
Не нужны нам твои цели, дружище. Нам твой бюджет нужен, и давай побыстрее зафиксируем все это на бумаге.
В процессе подключается более мелкий формализм – не будем делать работы сверх бюджета, не будем делать два варианта интерфейса, не будем работать над производительностью, если она ограничена платформой (а кто проверит?).
Еще в проектной документации, кроме целей проекта, пишутся критерии успешности. Вроде правильная штука – формула, по которой оценивается, был проект успешным или нет.
Когда речь о внутреннем проекте, выполняемом сотрудниками самой компании, то смысл в критериях есть. От них зависит карьера руководителя проекта и ключевых сотрудников. Сделал проект по сокращению бухгалтерии, если по факту бухгалтерия сократилась – ура, ты Великий Сократитель Бухгалтерии. Тебе с высокой вероятностью доверят сокращение экономистов. Или даже предложат, может и настаивать будут.
А если это внешний проект, с франчем? Кому нужны эти критерии успешности, если все этапы позади, акты подписаны, деньги заплачены? Ну, собственнику наверное нужны, чтобы в очередной раз убедиться, что не за что любить 1Сников. А если в первый раз с таким столкнулся, то поплакать и погрузиться в наш реальный мир.
Формализм сопровождает суррогаты везде. Чтобы это увидеть, надо лишь оглянуться вокруг.
Посмотрите на гос.управление. На законотворческую деятельность. На ваш город. На вашу управляющую компанию. Постарайтесь увидеть суррогат. Сейчас, кстати, самое время – скоро выборы. Кто сейчас вспомнит, какие перед этими ребятами стояли цели? Не такие, типа «развитие вверенной территории», а конкретные, измеримые, понятные. Они и сами не помнят. А что они будут вам впаривать в качестве результата своей работы? Да все что угодно – то, что вопреки формализму успели сделать, даже если это не они делали.
Построили детский сад – вот наш результат, скажут они. А цель какая была? Обеспечить всех детей от 2 лет детскими садами. Сколько для этого надо было дет.садов построить? 15, допустим. А они один построили. Суррогат? Ясен пень. Его еще и построил не город, а застройщик микрорайона, потому что обязан был.
Отвлекся. Второй кит – постепенность. Собственно, я его раскрыл уже, когда про формализм рассказывал.
Нет франча (хотя нет, есть один), который на первой же встрече скажет – пишем график, плевать на ваши цели, надо делать вот так и вот так, как напишем так и будет, никаких изменений в графике и бюджете, на проекте будет 2 специалиста и ни при каких условиях не добавится, ERP у нас никто не знает, будем учиться за ваш счет, портфолио на нашем сайте – фуфло, и т.д.
Все это заказчик узнает по ходу проекта, от первого до последнего пункта, плюс еще с десяток. Но узнает постепенно, иначе произвести суррогат не получится – просто не подпустят.
Постепенность крайне важна. При правильном использовании вектор проекта или продукта можно постепенно развернуть и на 180 градусов, и в змейку скрутить. Чтобы всей душой прочувствовать, насколько сильна постепенность, настоятельно рекомендую выбрать время и посмотреть фильм «Догвилль» Ларса фон Триера. Когда я был ИТ-директором, этот фильм был обязательным к просмотру для всех подчиненных программистов. Там, правда, цель была немного другая, более мелкая.
Фильм должен был показать программистам, как кит «постепенность» превратит их самих в суррогатов. Каждый программист ведь в душе считает себя архитектором, строителем системы, повышателем эффективности бизнеса. Это без иронии – так оно и должно быть.
А что происходит дальше с таким романтиком?
Пользователь: «А помоги мне настроить отчет…»
Программист: «Давайте я лучше вам расскажу, как вообще отчеты настраивать, сможете сами»
Пользователь: «Да сейчас некогда, начальник ждет, ну помоги»
Программист: «Ладно, сейчас»
…
Пользователь: «Нам бы распределение затрат настроить, месяц не закрывается»
Программист: «Я ж вам показывал, как это делать, обучение проводил, инструкцию написал»
Пользователь: «Ну что-то не получается у нас, помоги, тебе трудно что ли, ты ж программист»
Программист: «Нет, не буду, я вам не мальчик на побегушках, вам за это зарплату платят»
Пользователь: «Нам завтра прибыль сдавать, я директору скажу, что ты не помог, посмотрим потом, кому за что платят!»
Программист: «Ладно, в последний раз помогу»
…
Пользователь: «Слушай, у нас новый прайс с ценами поставщика, залей в 1С»
Программист: «Сам залей»
Пользователь: «В смысле сам? Ты ж программист»
Программист: «Я программист, а не оператор. Я программы пишу, а не данные вколачиваю»
Пользователь: «Да я не прошу вколачивать, залей, ты же умеешь»
Программист: «И ты умеешь, я тебе обработку написал, там только колонки надо выбрать, где номенклатура, где цена»
Пользователь: «Да не помню я, где она»
Программист: «Ну так ищи, письмо от меня было, в декабре вроде»
Пользователь: «Слушай, мне некогда, через час совещание по тендерам, надо чтобы данные уже в системе были. Заливай, или я скажу, что из-за тебя нам тендер продлевать»
Программист: «Ну ты скотина. Давай свой файл и готовься к совещанию, я все расскажу»
Так пропадают программисты на заводах, превращаясь в суррогаты. Дружат с бухгалтерией и пользователями, помогают закрывать месяц, загружают/выгружают файлики, толкают руками обмены во все стороны, исправляют минуса в оборотке, добавляют очередные поля в заказы, обновляют релизы и… продолжают мечтать, слава Богу.
Диалоги вы сами можете дополнить, все мы видели такие грустные истории – и на своем, и на чужом примере. Если не врать себе, конечно. Это – постепенность. Есть еще другой синоним в данном контексте – рутина. Которая, как известно, убивает брак, отношения с детьми, мечты и личные цели, и т.д. Все, завязываю, слишком грустная тема.
Остался последний кит – круговая порука. Она бывает явной, бывает «как-то само сложилось». Но без нее индустрия суррогатов не выживет.
Все, что я написал про работу франчей, я написал про все франчи. Это – результат круговой поруки.
Если вы – заказчик, вы не найдете франча, который будет действовать по-другому. Ну т.е. есть те, кто еще хуже действует, но лучше – нет. У всех одинаково. Конкуренция – только по второстепенным критериям, типа количества специалистов и неподтвержденных компетенций.
Франчи, конечно, нашли себе отмазку – вендора. Внедрения программ 1С получаются такими, потому что программы 1С такие. Почитайте холивары по этой теме на партнерской конференции, если доступ есть. «Мы для вас деньги зарабатываем, а вы такую плохую программу сделали, и нас не слушаете!». Я не защищаю 1С, она в этом не нуждается, но, все-таки, если голову из неправильного места вытащить, то придется признать, что проблема проекта – это проблема проекта, т.е. «временного предприятия, направленного на создание уникального продукта, услуги или результата (см. PMBOK)», а не внедряемого программного продукта.
В условиях круговой поруки главное – чтобы она не нарушалась. Как только хоть один франч научится реально достигать целей заказчика, всем остальным придется развиваться. А развиваться – это зло для производителей суррогата. Зло лютое, т.к. грозит потерей многомиллионного бизнеса, ведь речь о развитии сотен и тысяч человек, перестроении подходов к ведению бизнеса, процессов, проектных технологий и т.д. Даже подумать страшно.
Не правда ли, напоминает пресловутое гос.управление? Там круговая порука – это требование к сотрудникам. Читали когда-нибудь требования к гос.чиновникам? Я читал несколько лет назад. Черным по белому написано – запрещено говорить кому-нибудь что-нибудь плохое о гос.управлении, государстве и других чиновниках. Вроде как сор из избы не выносить.
Но не все так плохо. Этот мир нельзя избавить от суррогатов, но можно очистить от них себя, свою команду, свой отдел, свою компанию. Но это уже другая история, и не одна.
Важно помнить о китах – формализм, постепенность, круговая порука.
Если есть возможность – избегайте формализма, особенно если вы на фиксе. Работы для программиста всегда много, в любом регионе страны. Пробуйте делать без ТЗ, без требований и бумажек. Пробуйте достичь цели. Пробуйте понять цель. Помогите понять цель. Постарайтесь сделать больше и лучше, чем от вас требуют. Повышайте свой кругозор и эффективность – это выход за формальные требования к вам. Изучайте новые технологии и фреймворки.
Помните – человек, который к вам пришел (в т.ч. ваш руководитель), скорее всего сам – суррогат. И задачу принес суррогатную. И цель ему поставили суррогатную. Помогите ему вырваться из этого круга. Только не объясняйте ничего про суррогаты. Никто не любит слушать о себе гадости.
Не попадайтесь на постепенное превращение в суррогат, в придаток системы. Если у вас команда, разговаривайте о целях – рабочих, личных. Если вы руководитель – создавайте условия, при которых люди будут разговаривать.
Не давайте забыть, кто такой программист. Какие у него возможности, что он может дать бизнесу. Ради чего все это затевалось – и профессия, и это место работы.
Если вы – руководитель, и ваши люди превратились в суррогаты, производящие суррогат – помните, это ваша вина. Это люди, а не станки и не биоматериал. Вы отвечаете и за их результаты, и за их развитие. Иначе вы не руководитель, а
Ну и наконец, не поддавайтесь круговой поруке. Не делайте ставку на технологию или решение, которое все назвали хорошим. Не пропускайте решение только потому, что его назвали плохим. Найдите время, посмотрите, изучите, составьте собственное мнение.
Помните, что масса, связанная круговой порукой, говорит только то, что выгодно для сохранения круговой поруки.
Ну и самое лучшее – разорвите круговую поруку. В программировании и автоматизации даже один человек способен сделать революцию. Пока.
Комментарии (96)
vagonovozhaty
15.12.2017 23:25Суррогаты
thatsme
15.12.2017 23:33В процессе подключается более мелкий формализм – не будем делать работы сверх бюджета, не будем делать два варианта интерфейса, не будем работать над производительностью, если она ограничена платформой (а кто проверит?).
Ну это только вопрос финансов. Даже не сроков. И это не формализм, это рациональный подход к трате времени не задаром.
По сути, все всегда продают своё, или чужое (нанятое) время (невосполнимый ресурс). Если у заказчика есть бюджет на двойную работу (2 интерфейса вместо одного), почему-бы и не сделать. Однако, тратить время на то что не приносит прибыли, или даже в убытки вводит (сверх бюджета), совсем не разумно. Заказчик чаще всего и цели-то толком не видит. Он хочет кнопку «сделать хорошо», за 0 рублей 13 копеек и месяц работы. У заказчика отделы между собой точно также воюют: одним система вообще не нужна, — она-же их контроллировать будет, другие не понимают зачем это всё если есть Excel и электронная почта, третьи считают, что вся эта автоматизация есть формализм, для того что-бы у них красть время, которое они могут потратить на котиков в «тырнетах».
Главный, наверное, формализм, вы все о нем знаете. Это первый этап производства суррогата. Начинается с фразы «давайте теперь зафиксируем на бумаге».
В любых системах построеных на доверии, это доверие всегда подрывается. Именно поэтому существуют договоры и юристы. Если ничего не «формализировать», то будешь до ишачьей пасхи удовлетворять заказчика в лице лебедя, рака и щуки, причём бесплатно, из любви к искуству.
К 1С я отношения не имею, но насмотрелйся на ситуации когда люди хотят, чего-то одного вначале потом понимают, что хотели чего-то совсем другого и странного, а платить за это не хотят.
gearbox
16.12.2017 00:30Не вариант пройти мимо человека смотревшего и ПОНЯВШЕГО догвилль! Держи респект, незнакомый но приятный мне набор пикселей на мониторе!
Dementor
16.12.2017 01:37Что-то такое я уже читал в прошлом месяце на Инфостарте. Ну просто буква-в-букву! :)
infostart.ru/public/703188
И тогда же в вашем личном блоге:
business-programming.blogspot.ru/2017/11/blog-post_23.html
selivanov_pavel
16.12.2017 06:01Дружат с бухгалтерией и пользователями, помогают закрывать месяц, загружают/выгружают файлики
Это вообще не к программисту вопрос, а к менеджменту. Если рабочий процесс организован так, что сотрудники отказываются осваивать собственный рабочий инструмент, а всё время дёргают IT, чтобы они делали за них их работу — это ни разу не проблема программиста. Максимум, что он может сделать — это донести до менеджмента сложившуюся ситуацию. Причём, если менеджемнт поозволяет складываться такой ситуации, то скорее всего в этом случае он получит разнос и пойдёт снова выгружать файлики.
svcoder
16.12.2017 06:53В подавляющем большинстве подразделений иностранных компаний в россии, с которыми мне приходилось работать — есть бюджет на автоматизацию на год. То есть франчу говорят — давайте что-нибудь автоматизируем. Вот сидит тетя и грузит раз в день файл вручную, давайте сделаем чтобы файлы грузились автоматически, а тетя получала уведомления об ошибках загрузки, либо уведомления получал администратор, если за 1 день с момента попытки загрузки файл так и не был загружен.
Вы думаете тетю после этого тетю сократят? Нет, ей просто найдут другое занятие. Автоматизацию приводит к сокращения только, если до этого учет ведут на бумаге низкоквалифицированные сотрудники… Если в компании основные бизнес-процессы уже автоматизированы, высвобожденное время сотрудников будет использовано по-другому — контроллинг, расчет kpi, составление планов и анализ их выполнения. Когда-нибудь и эти процессы будут автоматизированы.
Есть особо продвинутые компании, которые считают, что если проблема возникла по вине человека — то он в этом не виноват, виновата компания, которая не автоматизировала данный участок работы и не прописала в коде необходимые ограничения и проверки.
Вы описываете внедрение 1с в компании, руководство которой пока не понимает цели проекта. Обычно они хотят внедрить сразу все, а в результате часть внедряемого функционала не будет использоваться. Благодаря автоматизации некоторые компании только начинают понимать, что такое процессы, зачем нужна сертификация ISO 9000 и зачем их автоматизировать.
svcoder
16.12.2017 07:04Еще хотел бы добавить, что западные компании рассматривают автоматизацию как инвестиционный проект, профит от которого будет до тех пор пока компания существует. Отечественные компании рассматривают автоматизацию как затраты, поэтому хотят сделать все быстро, дешево и часто собственными силами. Хотя зачем развивать собственных ИТ-специалистов, если компания, например, изготавливает мебель.
Am0ralist
16.12.2017 13:44Хотя зачем развивать собственных ИТ-специалистов, если компания, например, изготавливает мебель.
Затем, что готовые решения дороги, убоги и делаются по выше описанной схеме.
Пишу как человек, который за три года отправил несколько тысяч писем в тех.поддержку конструкторского ПО для мебели.
При этом решений для автоматизации приема и учета заказов мебели по индивидуальным проектам — по сути не было. Что-то наиболее близкое из готового — зарубежные за много-много-много лямов, что для мелких контор — нереально. А готовые 1С конфигурации за пару сотен тысяч — явно заточены под стандарт.
Все же внешние конторы заинтересованы только в вытягивании ваших денег, а не решении ваших задач.
DrPass
17.12.2017 00:43+1Хотя зачем развивать собственных ИТ-специалистов, если компания, например, изготавливает мебель.
Работал в компании, которая продает ГСМ. Развивать собственных ИТ-специалистов позволило снизить расходы на ИТ примерно в три раза, при значительном повышении качества услуг. Математика простая: специалист ERP из консалтинговой компании обойдется в $50/час, при этом он, грубо говоря, гость из дальнего космоса. В компании должен быть человек, который собирает пожелания пользователе и формализует их, затем наемный специалист должен въехать в бизнес-процесс, понять, как это должно быть реализовано (при необходимости объяснив пользователям, почему оно будет не так, как они просили), наконец, реализовать/оттестировать/отдеплоить, и снова улететь к себе на Альфу Центавру, или откуда он там прилетал.
Собственный специалист будет получать ставку $15/час (те же $50 минус прибыль консалтинговой компании, минус их налоги, минус их операционные издержки), при этом устраняется лишнее звено коммуникации, вон он тут всегда рядом, возле пользователей, ежедневно сталкивается с одними и теми же процессами, знает все проблемы и перспективы одной конкретной системы. Поэтому если ваши постоянные задачи по сопровождению и развитию ERP-системы способны хотя бы процентов на 70 загрузить работой одного специалиста на фуллтайме, берите его в штат. Так вам будет лучше.svcoder
17.12.2017 12:48Мне кажется вы путатете внедрение новой функциональности и поддержку существующей. Вот нет, например, в компании бюджетного управления, кто по вашему сможет его поставить? Собственные специалисты почитают книжки, сходят на семинары по бюджетированию, а затем начнут разрабатывать собственное решение или кастомизировать существующее? С огромной степенью вероятности, что при таком подходе вообще ничего не будет сделано или сделано не то, что требуется бизнесу.
Если бизнесу удалось найти специалистов, которые готовы в вникать в новые темы и внедрять новую функциональность, то тактически бизнесу это действительно выгодно. Но возрастают риски, что данные сотрудники могут просто напросто свалить, к тем же самым интеграторам, т.к. там и проекты интереснее и доходы выше. А компания останется с функциональностью, на которую даже нормальной документации нет.
В определенный момент времени у действительно сильных аналитиков и разработчиков возникает потребность получать деньги не за время, а за опыт. Они захотят писать собвенные курсы или делать тиражное ПО. Такие возможности конечный клиент никогда не предоставит.
Возможно поэтому западные компании вкладывают деньги только в развитие компетенций, связанных с основной деятельностью, а все остальное передать другим компаниями. Именно поэтому у них такая высокая доля сферы услуг в экономике, а у нас завод может выпускать откровенное гамно, но зато у в нем может быть отличная столовая.DrPass
17.12.2017 18:11Нет, я и внедрение также имею в виду. В любом случае для внедрения того или иного функционала нужная компетенция должна быть в первую очередь у менеджмента компании. Это они первыми должны читать книжки и ходить на семинары, независимо от того, кто будет внедрять, собственные спецы или приглашенные.
Если брать бюджетирование, к примеру, то у него техническая составляющая всегда более-менее одинаковая, и опытный разработчик в ней разберется за достаточно короткое время. А специфические для бизнеса процессы в любом случае надо будет долго и мучительно прорабатывать/рефакторить вместе с менеджментом и ключевыми пользователями, независимо от того, кто внедряет.
Возможно поэтому западные компании вкладывают деньги только в развитие компетенций, связанных с основной деятельностью, а все остальное передать другим компаниями.
Есть такая стратегия в управлении предприятием — отдавать на аутсорс все непрофильные направления. Но она, скажем так, имеет рамки применения. В общем случае это хорошо работает в двух кейсах:
а) если у компании есть много денег, и нет цели снизить издержки, зато есть цель разгрузить менеджмент
б) если компания маленькая, и постоянные издержки на содержание непрофильных направлений превышают эффект от снижения переменных.svcoder
17.12.2017 20:00У менеджмента никогда не бывает времени для приобретения новых компетенций, у него и без этого задач хватает.
Ну если у бизнеса есть ресурсы проторивать дорогу к результату методом проб и ошибок — ради бога. учитывая состояние нашей экономики, большинство компаний именно этим и занимаются.DrPass
17.12.2017 20:15У менеджмента никогда не бывает времени для приобретения новых компетенций, у него и без этого задач хватает.
Вообще-то как раз строго наоборот, это одна из его первоочередных задач, и если менеджмент не приобретает новые компетенции, значит, он не развивает компанию. Если компания не развивается, её выбрасывают с рынка те, кто развивается.San66
18.12.2017 15:37Развитие компетенций менеджмента обычно лежит в области менеджмента а не техники. Управление людьми и процессами гораздо более сложная история, чем программирование.
VolCh
18.12.2017 15:50Чтобы поставить технарям задачу на реализацию какой-то системы или фичи в существующей, у менеджмента должно быть достаточно компетенций, чтобы, хотя бы, знать о том, что эту задачу в принципе можно решить, чтобы мысль о реализации вообще пришла в голову. У нормального менеджера не должно возникать мысли "а что так можно было?", когда видит, что конкурент получает преимущество благодаря внедрению какой-то технологической новинки.
DrPass
18.12.2017 16:10+1Никто и не говорит о том, что менеджер должен для своего развития учить Турбо-Паскаль и установку винды. Но выяснить, какими средствами можно внедрить электронный документооборот в компании, или какие есть новые решения по автоматизации склада, это вполне себе достойная задача для профильного руководителя. Причем выяснить настолько, чтобы поставить конкретные цели и задачи своим специалистам и проконтролировать их выполнение.
San66
18.12.2017 22:28Если это входит в его круг обязанностей, то да. Но обычно внедрением и сопровождением занимаются другие специалисты, им это на откуп и дается.
DrPass
19.12.2017 01:44Не совсем так. Наличие хотя бы одного топ-менеджера, который курирует внедрение автоматизации любого крупного бизнес-процесса(и соответственно, разбирается в проекте), обязательно. Без этого проект просто «не взлетит».
VolCh
17.12.2017 02:01На одни переговоры и формулировки задач/требований для ИТ-подрядчиков может уйти столько времени топов компании, на которые можно нанять небольшую, но свою команду разработки.
svcoder
17.12.2017 13:00Это особенность советского менталитета, иметь все свое. Свою дачу, свой огород, свою лодку. Но на практике оказывается, что затраты на владение имуществом превышают плату за его временное пользование.
Что вы будете делать с командой разработки после того как проект закончится? Или вложите вы в них деньги, обучите, а они потом свалят к тем же ИТ-подрядчикам?algotrader2013
17.12.2017 13:22+1Да как-то не заканчиваются проекты. Аппетит приходит во время еды. Раньше бизнес не то, чтобы не хотел, а просто не понимало, «а что, так можно было». Как только автоматизировали что-то одно, тут же появляется масса идей, что надо разрабатывать далее.
VolCh
17.12.2017 14:24Для развивающегося бизнеса (в смысле не в состоянии стагнации) проекты не заканчиваются. Нет состояния "всё, нам больше ничего автоматизировать не нужно, всё идеально", даже без учёта постоянных изменения требований и рекомендаций регуляторов. Естественно, содержание команды всего из двух взаимозаменяемых специалистов (двух — для минимизации рисков "попал под троллейбус"), подходит не каждому даже среднему бизнесу, не говоря о малых.
tyomitch
17.12.2017 20:54Я в одной мелкой неайтишной фирме работал «летним программистом» в каждые университетские каникулы :-)
Для программиста на полную ставку у них работы не было, а в таком режиме — девять месяцев записывать возникающие задачи на бумажку, и потом за три месяца их все решить — получалась оптимальная нагрузка.
Теперь та фирма уже выросла и обзавелась постоянным программистом. Одним. Если он попадёт под троллейбус — компания погорюет, но бизнес не рухнет: начинался он вообще без айти, через телефоны и факсы.
С «айтишниками по вызову» они экспериментировали, но те оказались слишком накладными: чтобы за полчаса починить проблему, наёмному консультанту нужен час на дорогу, час на объяснение проблемы, и потом час на дорогу обратно, всё это за счёт заказчика.
DrPass
17.12.2017 20:20Что вы будете делать с командой разработки после того как проект закончится?
А что такое «проект закончился»? Проект по внедрению учетной системы обычно заканчивается в двух случаях — если от неё отказались и внедряют другую, либо если развитие бизнеса прекратилось. Если есть своя команда разработки, то первое обычно не происходит. А если произошло второе, то вопрос, что там будет с командой разработки, далеко не главная проблема для руководства компании.svcoder
17.12.2017 20:36Откуда вы черпаете информацию о вечных проектах?
DrPass
17.12.2017 20:41Они такие обычно и есть, странно, что у вас какой-то другой опыт. Естественно, я не имею в виду внедрение 1С: УТП для SOHO, а что-то более крупное, предполагающее бизнес-анализ и кастомизацию.
svcoder
17.12.2017 20:48Все проекты завершаются либо в установленный срок, либо завершаются вне установленного срока, но всегда завершаются. Вы явно что-то путаете.
DrPass
17.12.2017 20:56+1Не путаю. Если вы имеете в виду проект как договор и техническое задание в папочке с подписями, то да, конкретно у этой штуки есть свой определенный срок жизни. Если мы говорим о проекте по внедрению учетной системы, то он состоит из кучи таких папочек, и после завершения одной появляется следующая, пока работает система или идет бизнес. Первоначальное внедрение переходит в эксплуатацию/сопровождение, периодически появляются крупные задачи по внедрению какого-то нового функционала или по миграции на новые версии и т.д.
Bookvarenko
16.12.2017 07:59Про книжки всё вообще прекрасно. Особенно когда мелкий бизнесмен читает про гигантов индустрии. Самый любимый раздел про зарплату работников, производительность труда и мотивацию.
EvilBeaver
16.12.2017 09:58Спасибо за статью. Кстати с SAPом ни разу не лучше, даже еще хуже, потому что в десять раз дороже и потом никто не признается, что спустил миллионы долларов на суррогат. Проще суррогатно написать, что проект успешен.
andyudol
16.12.2017 10:24И как наиболее заметное проявление суррогатизма — любовь к модным словечкам.
EvilBeaver
16.12.2017 10:59Ну и да, тов. Белокаменцева я угадываю по стилю, не заглядывая в профиль автора:)
FreeMind2000
16.12.2017 11:08По словам автора статьи
Бизнес не любит: Реализовывать конкретные задачи
Бизнес любит: Ставить абстрактные задачи
Другими словами по вашему бизнес — это лентяй, который любит мечтать, но не любит сам работать, что бы воплотить свои мечты в жизнь.
Под работай в данном случае имеется в виду:
— проанализировать/найти/выбрать конкретный способ реализации своих мечт, потом
— проанализировать/найти/выбрать/нанять/заключить договор с конкретным исполнителем, потом
— проанализировать/составить план по срокам и качеству этапов работ выполненных исполнителем, потом
— организовать условия для работы исполнителя на своей территории, потом
— контролировать сроки и качество этапов работ выполненных исполнителем в соответствии с планом и в случае проблем незамедлительно принимать меры, потом
— проанализировать/принять/оплатить работу исполнителя, потом
— использовать/поддерживать реализованную мечту, потом
— анализировать/оценивать эффективность от реализованной мечты в реальности и той, что ставилась в самом начале.
После каждого пункта у меня стоит слово «потом», которое можно интерпретировать как «после чего», но те, кто в теме, думаю воспринимают его в другом смысле.
Большинство руководителей бизнесов, особенно государсвенных предприятий, любят мечтать — но не любят потеть.Am0ralist
16.12.2017 13:49Большинство руководителей бизнесов, особенно государсвенных предприятий, любят мечтать — но не любят потеть.
я б перефразировал: «любят мечтать, но не умеют решать»
Areso
16.12.2017 14:26«Так пропадают программисты на заводах… и… продолжают мечтать, слава Богу». Сколько работал, меня считали странным только за то, что я умею мечтать. Причем, если бы меня считали странным другие люди, я бы счел это нормальным, но нет, меня считали странным коллеги.
PaulAtreides
16.12.2017 18:11Это называется культ Карго. Вот смотрит руководитель: люди бормочут в микрофоны и самолёты прилетают. И думает, пусть мои сотрудники тоже в палочки бормочут, тоже наверное самолёты будут прилетать.
SergeyUstinov
16.12.2017 18:35В палочки бормочут — это лайт версия. А большинство строят самолеты…
habrastorage.org/storage1/f3aa6ba3/3b986cea/836df5db/596c49be.jpg
И удивляются — почему не летают? :)))
SergeyUstinov
16.12.2017 18:32Мне кажется, что во втором списке «бизнес любит» все пункты ошибочные. :))
Если бы бизнес любил — он бы платил за пункты именно из второго списка. Но это не так.
Успешные проекты есть. Действительно успешные. Их не много, но есть. Некоторые из этих успешных проектов даже с использованием 1С. :)))
А то, что успешных проектов мало — так руководство в этом не очень заинтересовано.
Тут ведь дело не в том, чтобы рассуждать — чего мы хотим. А в том, чтобы действительно этого хотеть и действовать в этом направлении. Если директор «суррогат» — он будет много говорить о вещах из списка 2, но делать вещи из списка 1. И все остальные сотрудники тоже.
Так что не надо рассуждать о мифическом «бизнесе». Есть вполне реальные люди, с именами и фамилиями, которые принимают решения. И они в большинстве своем хотят вещей из списка 1, так как только в этом случае будут находиться в зоне комфорта.
michael_vostrikov
16.12.2017 19:01Это был первый этап формализма – подмена цели перечнем задач.
Как достичь цели, не выполняя задачи?
А они один построили. Суррогат? Ясен пень.
А что по-вашему будет лучше? Не строить ни один?
Когда я был ИТ-директором
Пробуйте делать без ТЗ, без требований и бумажек.А, ну понятно. Если вы начальник — да, можете делать без ТЗ. Потому что вы и так в курсе всех изменений. Потому что заказчик у вас один, сотрудники компании, и они к вам и так идут с любыми доработками, то есть нет убытков от ситуации "сделайте мне в 2 раза больше за те же деньги". И потому что конкретно в вашей компании это нормально. Но для большинства программистов это вредный совет.
Вы имеете в виду какую-то свою ситуацию, только непонятно какую.VolCh
17.12.2017 02:43Дело не в том, что задачи не нужны, дело в том, что после формулировок задач о целях часто забывают, целями становится формальное выполнение задачи. Грубо, цель: уменьшить время обслуживания клиента, одна из задач — разбить сбор полного пакета документов с него на два этапа — минимально необходимый для предварительного предложения и остальные. Разбили, задача выполнена, но оказалось, что время увеличилось, поскольку:
— исполнители задачи не подумали о том, что во время ожидания предварительного решения можно и нужно переключиться на другого клиента, а не смотреть 5-10 минут на «ждите»
— у 50% клиентов и так только минимально необходимый комплект документов и по ним сразу можно принимать полное решение, не ожидая сообщения о предварительном решении, с тем чтобы отправить вторую форму пустой.
-michael_vostrikov
17.12.2017 09:47Ага, теперь понятнее. Но я так понимаю, в этом случае неважно, на словах решили разбить или письменно. В обоих случаях можно отнестись формально «ты сказал мне разбить — я разбил». То есть дело не в наличии ТЗ, а в том, что надо для любой задачи обозначать цель, и проверять ее после реализации, возможно в виде отдельной задачи, и по результатам список задач корректировать. Это подразумевает участие лиц, которые могут решать, как тратить время работников — или начальников, или самих работников с большой свободой действий.
VolCh
17.12.2017 14:32Не важно, да, в целом, но подмена целей задачами как раз признак (или этап) формализма, не важно письменного или устного.
Это подразумевает вовлеченность и мотивированность исполнителей в достижении цели, в не в решении технических задач. При большом количестве формализаций (форма не важна в целом, но обычно где-то письменная всё равно присутствует) легко получить ситуацию, когда даже непосредственный постановщик технических задач непосредственным исполнителям (условный техлид в команде разработки) уже ничего не знает о целях, фокусируясь на технических задачах.
timelle
16.12.2017 19:21Посмею заметить, что за все пункты во втором списке надо платить деньгами.
А ещё собственник или управленец перед обращением к специалистам должен:
- уметь формулировать требования к услуге и продукту, которую заказывает,
- понимать зачем это нужно в его бизнесе
- понимать какие ресурсы нужны для содержания приобретенного продукта
- следовать рекомендациям специалистов, к которым обратился
- быть готовым менять бизнес-процессы в компании
Кто выполняет эти пункты, у того всё хорошо (в большинстве случаев). А если нехорошо, то тогда спрашиваем с подрядчиков согласно требований там, где они расходятся с реальностью.
Разумеется, нужно не стесняться и перед началом проекта закрепить требования к продукту или услуге. Эдакое QA.
Kroid
16.12.2017 22:40Чувствуется, что автор вначале придумал интересный ему концепт, а потом начал подгонять под него реальность. Этакая общая натянутость и, временами, логические противоречия присутствуют.
Суррогат – это когда сделали не то, что просили. Или не так, как просили. Или не сделали то, что просили. Или сделали, когда не просили.
Иногда бывает еще хуже. Когда сделали именно то, что просили.
Кстати говоря, в словосочетании «бизнес хочет/любит/не любит» что именно подразумевается под словом «бизнес»?
artemlight
16.12.2017 23:04В статье какой-то юношеский максимализм.
У бизнеса есть N миллионов рублей на имплементацию каких-то фич, потому что «конкуренты сделали это же за N*2 (или даже N/2) миллионов рублей», потому что ойти — это круто и современно, потому что облачные технологии, виртуализация, биткоин, мобильность сотрудников.
Именно этим живут все крупные интеграторы. Инфраструктура ради инфраструктуры — но у этих людей есть бабки на enterprise exchange cal, citrix+rds на всех сотрудников, сфб кал по числу реальных мобильных устройств и так далее. 50, 100, 300 тысяч рублей на рабочее место в год — да как нехрен.
А те, кто не придерживаются этих принципов — те работают за копейки.
San66
17.12.2017 00:10Не знаю как кому, но мне удивительно.
Внедрял на фирме 1С УПП, с ее приходом стало прозрачнее планирование, закупки, остаток на складе и проч. Короче доволен, гораздо лучше, чем в Экселе было до того. Правда 1С программиста не нанимали, изредка обращаемся за поддержкой в контору.
Был «Представителем руководства по СМК», правда требование было в основном чтобы «было всё по новому оставаясь всё по старому» так что в итоге пришлось ограничиться «меньшим злом».
Составление ТЗ на бумаге — если это не написать, то куча специалистов изо дня в день будут тянуть одеяло требований на себя и проект никогда не начнется, а начавшись, не закончится. А когда закончится, то выяснится, что оно никому не нужно, и все будут говорить «я же говорил, что нужно делать по другому!».
Короче ИМХО статья в стиле «Баба Яга против».
SbWereWolf
17.12.2017 09:43«Пробуйте делать без ТЗ, без требований и бумажек. Пробуйте достичь цели.»
мне как раз ТЗ помогает достичь цели, потому что без этого текста с картинками-диаграммами, как то быстро забывается куда надо идти и какой путь следует выбирать.
формализм нужен, но если документ сделали, то надо его актуализировать постоянно и постоянно с ним сверяться.
с круговой порукой согласен — люди когда не понимают, они бояться признаться что не понимают и ленятся разобраться.
постепенность — она во всё есть, надо о цели не забывать, опять же — сверяться с документом :)VolCh
17.12.2017 14:43Наличие ТЗ обычно предполагает уже чётко выбранный технический путь достижения цели. Собственно сама цель в ТЗ может быть и не указана. ТЗ — это вроде маршрута "поверните налево, поверните направо — вы прибыли на место назначения", в котором место назначения вообще может быть и не указано.
SbWereWolf
17.12.2017 16:14мне как исполнителю большего не надо :) моя цель что бы при пинке с силой N по реализованному чёрному ящику звучал звук У определённой тональности и громкости, цели вызывать в слушателях определённых эмоций я не ставлю, это цель интегратора и владельца чёрного ящика, моё дело этот ящик сколотить и покрасить.
VolCh
17.12.2017 16:32Есть мнение, что подобная позиция исполнителей снижает эффективность достижения целей. :)
SbWereWolf
17.12.2017 17:31есть мнение что руководство и аналитики занимаются целеполаганием, а не исполнители.
VolCh
17.12.2017 21:13Целеполаганием, да. Но есть мнение :), что эффективнее исполнители работают, когда понимают что и зачем они делают. Даже чисто психологически, если, конечно, им интересны эти цели. Одно дело решить задачу типа: "уменьшить время отклика страницы до N ms" и другое "увеличить конверсию путём уменьшения отклика". Это не говоря о возможности, что исполнители предложат лучшее решение по достижению тех же целей.
SbWereWolf
17.12.2017 23:39тем не менее ТЗ полезный документ, дать возможность познакомиться с целями проекта, то будет не лишним, ок :)
Am0ralist
18.12.2017 00:16тем не менее ТЗ полезный документ
Должностная инструкция — тоже.
Помните суть итальянской забастовки?SbWereWolf
18.12.2017 07:28обожаю этот документ, там вечно хрень полная написана и её ни кто не хочет менять. Я один раз даже из-за этого уволился.
Итальянская забастовка это когда сотрудники динамят, как бы ни каким формализмом и KPI человека не заставить работать по совести, поэтому относиться к документам как инструментам гарантии 100% качества это не разумно.
Тем не менее документы описывают рамки, я когда техподдержкой занимался, по прочтению договора узнал много нового и половину заявок стал заворачивать как не относящиеся к делу, потому что завод (и не только) обнаглел и тупо сел на шею.
Моё мнение документы, очень важная штука как ориентир. Для меня, качество моей работы без них страдает.Am0ralist
18.12.2017 11:08обожаю этот документ, там вечно хрень полная написана и её ни кто не хочет менять.
В ТЗ, знаете ли, тоже может быть написана хрень, которая при внимательном рассмотрении никак не решит озвученные цели…
Итальянская забастовка это когда сотрудники динамят,
Что значит динамят? Они абсолютно не динамят. Они выполняют от и до то, что от них требуют по инструкциям. От и до. С ТЗ может быть абсолютно тоже самое.
Тем не менее документы описывают рамки, я когда техподдержкой занимался, по прочтению договора узнал много нового и половину заявок стал заворачивать как не относящиеся к делу, потому что завод (и не только) обнаглел и тупо сел на шею.
То есть начали динамить завод, по вашему собственному определению итальянской забастовки. Один в один)SbWereWolf
18.12.2017 12:12ТЗ переписывается и согласуется, а должностная инструкция написана 100 лет назад и больше не меняется, потому что должностная инструкция это отдел кадров, а ТЗ это непосредственный заказчик и непосредственный исполнитель. Разные отношения.
я завод не динами, это завод от меня требовал лишнего, завод требовал выполнения работ которые в техподдержку не входят, требовал работ выходящих за рамки договора.
всегда можно передёргивать, а можно не передёргивать. зависит от воли и исполнителей и руководителей.Am0ralist
18.12.2017 12:21ТЗ переписывается и согласуется, а должностная инструкция написана 100 лет назад и больше не меняется, потому что должностная инструкция это отдел кадров, а ТЗ это непосредственный заказчик и непосредственный исполнитель.
Даже если должностная будет переписываться каждые пять минут — проблему не решить: либо будут настолько размытые формулировки, что ты будешь выполнять обязанности грузчика-системного архитектора, либо сочинение в 10 томах на каждую должность с обязательством знать их наизусть.
я завод не динами, это завод от меня требовал лишнего
Так и люди никого не динамят при итальянской — но вы это назвали именно так. Люди в этом случае тоже не делали того, что с них требовали лишнего.
Еще раз, ситуации абсолютно идентичны.
vryashentsev
19.12.2017 07:17Мало того, Джим Коллинз описывает, что все великие компании отличались тем, что объединяли всех своих сотрудников общей идеологией, которая позволяла им работать сообща. Понимаете? Все! Чувствуется присутствие цели?
Остальные же компании оказались менее жизнеспособны или долговечны, не смотря на то, что в какой-то период достигали очень хороших показателей. Короче, узкая ответственность и отсутствие видения общей картины — путь к посредственности.
sevenlis
19.12.2017 09:22+1Блин. Диалоги программиста и пользователя прям до слез. Вы за мной следите? У меня таких диалогов 3-4 на день. 80% отлуп наглым пользователям )))
VladNskSu
19.12.2017 09:23+1Среднестатистический мужчина не любит:
1. Заниматься в спортзале.
И, как ни странно, среднестатистический мужчина любит
1. Красивое мускулистое тело без капли лишнего жира.
Хотел было написать простыню текста с разбором ошибок в тексте, но, надеюсь, текст выше покажет в чем главная ошибка автора.
Разумеется, франчи никак не ангелы, но рассказывать что виноваты в провалах внедрений только они, а бизнес прям весь белый и пушистый — признак полного непонимания ситуации.
zorggroz
19.12.2017 09:23+1Товарищ Иван Б. уже здесь, правильно нужно охватывать так сказать правильными мыслями как можно большую часть общества, прогрессивного общества.
onborodin
19.12.2017 09:23Вы в своей статье описали то, что достаточно разжевано в COBIT 5, Implementation, p8-60 и далее.
В том числе, но не только, слабое вовлечение и деловую некомпететность разработчиков, как часть пост-советского профайла.
В том числе, но не только, крайне слабую проектную, в смысле PRINCE/PMBOOK и вообще социально-деловой зрелости, компетенцию всех участников деловых процессов.
В контексте архаичной коррумпированной и выродившийся социо-экономики.
banand
19.12.2017 09:23Суррогатизм он наверное в большинстве торгово-производственных компаний обитает. По другому бизнес не умеет. Гонка за быстрой прибылью и жадность собственников превращает ит в суррогат.
ClosedSneaky
19.12.2017 09:23«Основная задача персональных вычислений — формализация профессиональных знаний — выполняется, как правило, полностью самостоятельно непрограммирующим профессионалом или при минимальной технической поддержке программиста, который в этом случае имеет возможность включаться в процесс формализации знаний только на инструментальном уровне, оставляя наиболее трудную для его понимания содержательную часть задачи специалисту в данной предметной области.» (ТЕХНОЛОГИЯ АВТОФОРМАЛИЗАЦИИ ПРОФЕССИОНАЛЬНЫХ ЗНАНИЙ Г.Р.Громов.)
Дело в том, что разработчик на платформе 1С — это и есть «непрограммирующий профессионал», а, следовательно, он обязан понимать содержательную часть задачи предметной области и решать основную задачу персональных вычислений. Противоречие возникает в тех случаях, когда специалист 1С забывает о том, что «формализм» это целиком его зона ответственности.
Методология учета, консультации и обучение пользователей также относятся к компетенции специалистов 1С. Понятно, что «истина всегда конкретна» и каждое внедрение ПО требует индивидуального подхода к клиенту, но тем не менее, всегда полезно соблюдать базовые принципы. Консультации и обучение, — почасовые услуги без ТЗ. Настройка типового решения 1С, — почасовые услуги без ТЗ. При разработке отраслевого решения на платформе 1С, необходимо соблюдать официальный перечень требований 1С, включающий требования к документации.
К сожалению, иногда происходит подмена понятий — логическая ошибка, заключающаяся в выдаче какого-либо программного продукта за решение, каким он заведомо не является, и в использовании несоответствующих контексту задачи определений.
Суррогат и формализм — это подмена понятий. Сам термин «формализм» не несет негативного смысла, даже напротив, в контексте программной разработки формализм напрямую связан с формальной логикой и дедукцией, для которой характерны: непротиворечивость, полнота, независимость, разрешимость. Формальное описание предметной области весьма ценно. В какой форме оптимально фиксировать формализованные знания это отдельный вопрос. Кому-то нравится спецификация через тестирование, кому-то списки требований в екселе, кто-то зачарован диаграммами UML простор тут большой. К большому сожалению, многие ограничиваются заметками в msword, в запущенных случаях по ГОСТ-34.VolCh
19.12.2017 10:11Термин "формализм" всё же содержит негативные коннотации в русском языке, например
ФОРМАЛИЗМ — приверженность внешним формам в ущерб содержанию. В области человеческих отношений проявляется в неукоснительном следовании правилам этикета, обрядности, ритуала даже в тех случаях, когда жизненная ситуация делает это нелепым и бессмысленным..."
Словарь терминов и понятий по обществознанию. Автор-составитель А.М. Лопухов. 7-е изд. переб. и доп. М., 2013, с. 441.
panvartan
19.12.2017 09:23Любит, не любит — в конечном итоге все сводится к тому, что конкретный бизнесмен может и чего он не может.
Draku1a
19.12.2017 18:23Бизнес не любит
— расходы
— расходы
— расходы
— расходы
При этом, бизнес любит
— доходы
— экономию
— сокращение расходов
— оперативность сведений
Бизнес… во всей красе…
Draku1a
19.12.2017 19:41Вообще, вся статья — в первую очередь, наезд на отрасль 1С (как на франчей, так и на фикси), причем не особо скрытый. С первого же предложения ясно.
За франчей заступаться не буду — на их стороне не был. Хотя примерно их понимаю. У них у самих бизнес, и их интересует как раз то, что перечислено во втором списке, а точнее — прибыльность. Своя собственная прибыльность, а не того — кому они внедряют продукт. Далеко не многие понимают, что действительно выгодная стратегия — это WIN-WIN, когда все в выигрыше.
С другой стороны — в инете можно найти довольно много баек и комиксов от Web-дизайнеров про своеобразность работы с заказчиками. Байки эти на жизни основаны. Поработаешь с парой-тройкой таких без ТЗ, и формализмом заниматься поневоле захочется.
Второй момент постепенность, или рутина. Приведённых примеры диалогов — это скрытое манипулирование. Ещё бывает в другом ключе «ты же умный, ты суперпрограммист, ...» и т.д., т.е. заставляют делать свою работу. В целом, тут главное придерживаться принципа — «Программист это тот, кто делает инструменты, а не тот кто с ними работает». Сделал механизм (отчет/обработку/документ), описал, обучил как с ним работать, и всё, не более. В идеале, программисту должно быть СКУЧНО выполнять монотонную работу с использованием собственных инструментов. Конфликты подобного рода обычно до руководства не доходят (проверено, не раз отказывал), а если и доходят — начальство принимает сторону программиста. И даже если не принимает — можно из этого извлечь выгоду. В виде оправдательной причины «почему вот эта задача выполнена на неделю/месяц/квартал позже, чем запланировано.
Третье — круговая порука, ну тут см. выше про франчей. Про фикси — скажу так: у них есть начальство, и это не владелец бизнеса. И это начальство требует решения определённых задач. Конкретных задач. ИТ-руководство, более приближенное к владельцу бизнеса, также имеет определённые установки и цели, поставленные этим владельцем. И никакой круговой поруки тут нет. Тупо погоня за быстрыми деньгами (франчи) или за премией к зарплате (фикси).
(P.S.) Как Вы думаете, почему бизнес обращается к 1С? Как ни странно — это дёшево. При этом, ещё помогает удовлетворить похотливые услуги нашего государства в плане отчётности по налогам, статистике и т.п.
Doomsday_nxt
Интересно… Бизнес не любит 1С-программистов… Но при этом, по моему городу (где зарплата в ИТ редко поднимается больше 30-40 тыс.руб.) вакансии 1С-программистов оцениваются минимум в 80-90 тыс.руб.
nmivan Автор
Высокие зарплаты программистов 1С — это не следствие любви бизнеса, а вынужденная необходимость — кто-то должен обслуживать то, что на хайпе навнедряли.
Doomsday_nxt
Но нужен именно хороший программист… Иначе не платили бы в два раза больше общего рынка…
В принципе бизнес не связанный с ИТ не любит ИТшников всех — потому что они только тратят (и мало кто задумывается о том, сколько они экономят)…
На одной из прошлых работ я через 2-3 месяца снизил затраты на сотовую связь на почти на 50 тысяч… И поддерживал этот уровень даже когда количество абонентов выросло на примерно 20%… Но когда я попросил прибавку к зарплате хотябы в 5-10 тысяч — меня грубо послали «в газпром за карьерным ростом»…
x07
Один известный банкир недавно сказал что программисты не нужны.
Areso
Вот пусть и ведет прием людей исключительно в офисах, данные отправляет на бумаге почтой)
Потом можно будет посмотреть, как долго просуществует такой банк в конкурентной среде (если речь идет о госбанке, то он выживет в любом случае, даже при ведении учета в гросбухах).
artem_dobrovinskiy
Речь о Сбербанке и Германе Грефе. Странно, что Вы такую хохму пропустили — мы всем офисом катались.
x67
Вот вы говорите «хохму» и вас даже как минимум 2 человека поддержало, а Греф между прочим вполне логичную вещь сказал. Если не вырывать слова из контекста. И конечно же анализировать только слова, не пытаясь оценить высказывание на основании вашего личного отношения к этой личности.
x07
Вот где карту открывали туда и идите.
Dessloch
Везде, где я работал, сталкивался именно с таким подходом. И это касается не только ИТшников. Любой рационализатор на производстве сталкивается с таким. Поэтому когда я вижу в стране беспорядок меня это нисколько не удивляет. Знаю причину.
artem_dobrovinskiy
О какой стране речь? Вы в каких работали?
Dessloch
Разумеется речь о России.
Dessloch
На самом деле всё очень просто. Бизнес не любит 1Сников, но 1Сников любят бухгалтеры. А не любить бухгалтеров бизнес не может и готов удовлетворять все их капризы. Фактически 1Сника на работу берёт главбух. Как главбух скажет так и будет. Скажет главбух-надо трёх 1Сников-будет три и никто спорить даже не будет-сократят уборщиц, урежут премию, но трёх 1Сников возьмут.