Это Спарта!

Публикация № 715604

Управление - Управление проектом

101
Как 1Сник помогает злу. И как прекратить это делать.

С чего все начинается

Представьте исходную ситуацию. К фикси-программисту 1С подходит человек – пользователь системы, он же – руководитель некоего подразделения. Просит, или предлагает, или просто нейтрально говорит – надо сделать в 1С такую-то штуку.

Программист, допустим, толковый – он понимает, что предлагаемая доработка – суррогат.

Вариантов развития событий много, я приведу некоторые из них:

  1. Программист говорит: согласуй с моим или своим начальником, тогда сделаю;
  2. Программист говорит: напиши мне задачу/поручение/служебную записку, на бумаге или в информационной системе (ДО, Битрикс, или что у них там);
  3. Программист говорит: нужно мнение вот этого и вон того человека, т.к. их интересы доработкой тоже затрагиваются;
  4. Программист говорит: твоя задача – суррогат, и добавляет что-нибудь из первых трех пунктов;
  5. Программист просто говорит: не буду делать;
  6. Программист говорит: задача бесполезная, или даже вредная, я сейчас всем скажу и докажу, что ты – дурак;
  7. Программист говорит: надо запускать внутренний проект, давай все согласовывай и организуй, и сделаем.

Все перечисленные варианты ответа объединяет одно – результат. В большинстве случаев это будет произведенный суррогат.

Программист ведет себя так, чтобы суррогат точно, обязательно и бесповоротно был создан.

Если сказать об этом программисту, он будет возражать, яростно возражать. Вот вы же возражаете? Или вообще уже перестали читать и убежали в фейсбук.

А почему?

Если вы еще здесь, то давайте разбираться, что не так с поведением. Попробуйте перечитать исходную ситуацию и варианты поведения программиста. Что объединяет перечисленные паттерны? Как поведение программиста качественно меняет исходную ситуацию?

Ответ прост – все варианты включают (в смысле нажимают ВКЛ) публичность. Кроме программиста и пользователя появляется третий, четвертый, десятый человек.

Публичность заставляет человека защищаться, отстаивать свои предложения, настаивать на их реализации. Просто потому, что задевается его чувство собственной значимости и авторитет.

Во многих компаниях корпоративная культура – консервативная и патриархальная. Там полно паразитов, много имитации бурной деятельности, мало фактов с цифрами и много подковерной возни, которую принято называть политикой.

Немного политики

Что самое опасное, вредное и смерти подобное в политике?

Вот вы ведь наблюдаете, хотя бы иногда, за политикой в стране и в мире. Что, по вашим наблюдениям, политики делают реже всего?

Признают свои ошибки.

Признание своих ошибок – это политическое самоубийство. Кто угодно может говорить о конкретном политике что угодно, обвинять его во всех смертных грехах, приводить доводы и факты.  Но политик никогда не признает свою ошибку.

Максимум, которого можно ожидать – ошибку признает не сам политик, а его подчиненные, желательно пониже рангом, и тихонечко, шепотом, обтекаемо, чтобы не навредить хозяину.

В корпоративном мире действуют те же законы.

Авторитет, карьера, зарплата, перспективы человека зависят от политических баллов.

Ад своими руками

И вот программист, видя потенциальный суррогат, бьет в самое больное место – публичную (=основную) жизнь политика. Суррогат выставлен на всеобщее обозрение, и табличка повешена: «Программист сказал, что это суррогат».

Человеку ничего не остается, кроме как всеми силами защищать свое политическое лицо, действуя в двух направлениях: убедить всех, что суррогат – не суррогат, а заодно устроить все так, чтобы программист оказался дураком.

Второе направление – это путь паразита. Раз уж программист выполз из своей норы и решил потягаться с серьезными людьми, надо создать условия, при которых он не сможет выполнить задачу или проект.

Кто не помнит, освежу: паразит – это тот, кто старается сделать так, чтобы задача не была решена. Прям применяет определенные действия для этого, задачу ставит так, чтобы не решилась, сроки ставит неправильные и т.д.

Это вообще оптимальный путь, убивающий сразу двух зайцев – и суррогат не воплотился (а значит, никто не проверит, был ли он таковым) и программист в дураках, т.к. не решил задачу.

Что неприятно, коллеги этого пройдохи пойдут тем же путем, т.к. паттерн оказался удачным. К программисту больше никто не будет приходить и спрашивать его мнения – задача сразу будет ставиться публично, чтобы суррогат был произведен с высокой вероятностью. А если не произведен, то хотя бы за счет программиста поднять свой политический рейтинг.

Тут уже работает другой феномен корпоративной культуры – кто первый говорит о проблеме, тот – молодец, получает пятерку, пополняет свои политические баллы. Такого народу и в бизнесе, и в жизни – тьма тьмущая.

«Хьюстон, у нас проблемы!» - и ждет свой лайк от руководства. Лайк пополняет баллы. Будет проблема решена, не будет – вообще не важно. Главное проблему найти и первым о ней заявить.

Кто нашел проблему, тот вроде и решать ее не обязан. Все вокруг обязаны. Особенно программисты.

Любой толковый паразит сходу назовет вам 10, если не 50 проблем в информационной системе, в которых виноват программист, только повод дайте. Особенно если у вас УПП, в которой уже все более-менее чего-то понимают, в т.ч. паразиты. Да и понимать-то не надо, достаточно сказать «тормозит», «отваливается», «из дома не могу работать», «с планшета не могу работать», «CRM плохой», «интерфейс корявый», «блокировки какие-то».

Ох, увлекся. Эта тема – разозленный политический паразит – не центральная в публикации. Она – следствие публичной демонстрации суррогата.

Итак, вот он ад во всем своем великолепии. На каждом совещании все наперебой говорят: автоматизации нет, задачу программисту поставили, а он ничего не делает, а у меня эффективность низкая без этой доработки, бла-бла-бла.

Я через такое проходил. Мне буквально мстили, ставя задачи. На каждом совещании – вот, я поставил ему задачу, требую назвать срок решения, я крутой управленец, а в ИТ бардак, я бы нанял внешний франч лучше, у меня еще 100500 задач для ИТ.

Политическая карьера человека, который говорил эти фразы чаще других, резко и быстро шла вверх. Я до сих пор удивлялся, как это возможно при столь скромных способностях.

Теперь, конечно, понимаю, что это, во многом, моя заслуга. Я в свое время очень активно выводил в публичное пространство все потенциальные суррогаты, руководствуясь благими намерениями.

В эффект получил обратный – суррогатов не только стали больше предлагать, но и их почти все пришлось реализовать, моими силами. Доходило до того, что мое мнение вообще игнорировалось всеми участниками процесса. И был дан прямой приказ – делай все, что говорят.

А начиналось все с малого – с публичности, с выноса сора из избы.

А решение есть?

Решений полно, вы сходу назовете несколько. Если не назовете, то предлагаю на выбор те, что использовал я. На высшую истину не претендую, универсальность не гарантирую, только для теоретического изучения.

Конкретно моя ситуация разрешалась удачно, и не один раз, а целых три, и всегда разными путями.

Путь бизнес-программиста

Первый путь – сложный, но в плане саморазвития очень полезный – разобраться в смежных областях и делать изменения самому, от начала до конца. Выявлять проблемы, формулировать задачи, придумывать решения, реализовывать их и внедрять. Это классический путь бизнес-программиста.

Суть пути – разобраться в работе других и быть проактивным. Второе важнее.

Проактивность измеряется легко. Проактивный бизнес-программист ставит себе задач больше, чем получает извне.

У меня процент задач и проектов, запущенных в работу по моей инициативе, доходил до 80-90.

Людям вокруг просто нечего было предложить для автоматизации, т.к. я все уже предложил. Оставались, в основном, мелкие задачи, с которыми я даже не спорил – просто выделял им определенный процент времени в неделю.

Путь бизнес-программиста решает проблему производства суррогатов на корню. Если помните исходную ситуацию, то на пути бизнес-программиста она просто не случается – никто не приходит и не просит и не требует чего-то автоматизировать.

Путь Главного

Этот путь встречается редко, но для полноты картины я его упомяну.

Путь бизнес-программиста привел меня на место Главного по стратегическим изменениям в компании. Говоря простым языком, все изменения в бизнес-процессах, автоматизации, стратегиях и т.д. были в моем ведении.

Тема стратегических изменений компании силами 1Сника – большая и интересная, но не особо относится к данной публикации, поэтому детально раскрывать не буду.

Главное, что важно в контексте суррогатов: когда ты Главный по изменениям, ты можешь смело посылать всех, кто принес тебе суррогат. Что я, собственно, и делал.

Путь Спарты

Путь Главного по изменениям привел меня к третьему, компромиссному и самому, на мой взгляд, жизнеспособному пути.

Есть такая методика, которая формулируется как «fail fast, fail cheap». Переводится как «проваливайтесь быстро, проваливайтесь дешево».

Эти принципы были разработаны в ИТ-среде, вроде бы в веб-разработке, и тесно связаны с гроузхакерами (growth hackers). Углубляться не буду, уже упоминал этих ребят несколько раз в других публикациях, у них есть чему поучиться. Они очень похожи на бизнес-программистов.

Кстати, Agile, которым повально увлекаются фетишисты менеджеры из всех областей бизнеса, тоже пришел из ИТ. Это ремарка тем дорогим ребятам, которые до сих пор считают, что все, чем могут помочь программисты бизнесу – решением задач автоматизации.

Возвращаемся к fail fast и суррогатам. Ключ в том, чтобы любое решение было сначала прототипом, предназначенным для проверки пригодности, и только потом становилось железобетонным, официальным и прописанным во всех инструкциях.

Fail fast это:

  • Быстро решили, делать или нет;
  • Быстро сделали прототип, самым коротким путем;
  • Быстро запустили в работу, на ограниченном круге самых адекватных лиц;
  • Быстро сняли результаты;
  • Быстро приняли решение – это fail или success;
  • Если fail – выкинули на помойку;
  • Если success – довели до ума (интерфейсы, производительность, обучение, инструкции, бумажки).

Теперь должно стать понятно, почему fast превращается в cheap (дешево). Потому что если делать «как обычно», то выходит значительно дороже. Сами знаете, как выглядят затраты на автоматизацию по принципу Парето. Fail fast использует те самые 20 % времени, пропуская 80 % до принятия решения о судьбе изменения.

Заметили, что fail fast очень похож на Agile? Эти штуки не заменяют, а хорошо дополняют друг друга.

Но главное, в контексте данной публикации – fail fast не пропускает суррогаты, не оставляет их в живых.

Помните, где такое было? Когда рождался мальчик, как и всех спартанцев, его внимательно осматривали. Если он был слишком мал, тщедушен, болен или уродлив, от него избавлялись. Это такой fail fast по-спартански. Или генетика, если хотите.

 

Как осуществить fail fast на практике, в нашей исходной ситуации?

Конечно, идеальная картина – когда все вокруг понимают, что такое fail fast, и он является нормой корпоративной культуры. Знаю, что у вас такого нет и не будет. У нас такого тоже не было и не будет. Но упомянуть стоило, вдруг вы, дорогой читатель, из другой страны.

Главный переключатель в fail fast – не включать публичность.

С публичностью никакого прототипа не получится. Вы будете делать все, что скажут, «от заглавной буквы У до тиража и типографии».

Нужно дать понять человеку, который к вам пришел, что ваша задача и цель – помочь ему, в т.ч. в политической борьбе. Призвать к непубличности этой автоматизации, объяснить почему предлагаете действовать именно так.

Если получится – отлично, сходишь и объявишь, какой ты молодец. Получишь свой лайк. Меня упомянешь, если есть желание (упомянет, будьте уверены).

Если не получится – никому не скажем, никто не пострадает, не нужно будет оправдываться и защищаться.

Ну и совесть перед собственником будет чиста, мы ведь не потратим много времени и денег. В случае ошибки потратим намного больше и, что значительно хуже, взвалим себе на плечи новый балласт – никому не нужный суррогат.

Если отношения с человеком неплохие, то можно даже смелее сказать: я знаю, что ты предлагаешь ерунду, но на словах я тебя убедить не смогу, давай сделаем прототип и ты убедишься. Или я пойму, что был не прав (эту фразу лучше ввернуть, чтобы была постелена соломка).

Ну и действовать. Максимально непублично. Это очень важно, и вот почему.

Даже если вы вдвоем отличные парни, понимаете что делаете и обо всем договорились, в компании всегда найдутся люди, которые захотят заработать политические баллы за ваш счет. Теперь уже не за счет лично вас, а на всей вашей уютной fail-fast-компашке.

Работа по fail fast – это почти всегда нарушение регламентов и процедур, потому что ничего не согласовывается, не оформляется, в график не включается.

На этом вы со своим новым дружбаном и можете погореть – на формальностях, точнее на их несоблюдении. Пострадаете оба, и дружба кончится – придется защищаться и оправдываться, чтобы восстановить свое положение. А виноват будет программист – он же fail fast предложил. Ну и второй раз подружиться уже, скорее всего, не получится.

Особое внимание надо обратить на дружбана – он первый, кто побежит хвастаться вашей непубличной работой по «современной методике менеджмента» fail fast. Понимаете, почему? Потому что он на этом политические баллы заработает.

У меня были такие случаи несколько раз, и если случался прорыв непубличности, то виноват всегда был один человек – тот, кто пришел ко мне со своими проблемами.

Работа по fail fast их так вдохновляет, особенно когда очень быстро появляются результаты, которые можно пощупать, что они не могут удержаться – бегут к коллегам, к руководству и начинают продавать свой еще не полученный результат, в обмен на лайки.

Результат всегда один и тот же – внимание руководства и завистников с формулировкой «а вы что там вообще делаете?». Ну а дальше по стандартному сценарию: а почему мой проект не делаете, а где согласование, почему пропущена стандартная процедура, где ТЗ, и т.д. Говоря проще, «почему не оформлен суррогат?».

 

Вы, как программист, особенно как 1Сник, понимаете, что такое fail fast. Вы применяете эту методику интуитивно каждый день. Написал, запустил отладку, проверил, двинулся дальше или переделал.

А в бизнесе так не умеют. Вы можете научить, и суррогатов станет меньше.

101

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Дата
213. 1c-intelligence 7979 06.07.18 09:30 Сейчас в теме
Друзья, прошу прощения за спам - поучаствуйте в голосовании.
212. herfis 281 04.04.18 13:24 Сейчас в теме
(211) Ok, ok. Calm down, all right. Don't worry, be happy.
211. David_1C 04.04.18 13:12 Сейчас в теме
(210) Странный не я вообще-то, а ты! Во-первых не лезь не в свой разговор, во-вторых объясняю. Я в бутылку не полез, а ответил так как мой пост прокомментировали. Вот эта приставка "как бэ"... "наш главбух который как бэ заинтересован .." говорит о том, что типа я не верно рассуждаю. Т.е. я "как бэ" не прав и моя вина в том, что у них главбух - генератор суррогатов. Если бы он сказал наш главбух - генератор суррогатов, без приставки "который как бэ" его коммент имел бы совершенно иной смысл. А так получается, типа я дурак и вот у них совсем другая ситуация и я в ней виноват... Вообще, учите русский язык, не будьте дегенератами! "Как бэ"...
210. herfis 281 04.04.18 12:42 Сейчас в теме
(209) Странный ты. Ты высказался, в том духе, что заинтересованные в конечном результате главбух и директор препятствуют созданию суррогатов. Тебе возразили, что эта заинтересованность - условие необходимое, но не достаточное. А ты в бутылку полез.
209. David_1C 04.04.18 04:56 Сейчас в теме
(157) уважаемый, а что значит "как бэ"? Это типа из-за того, что у тебя главбух генератор суррогатов я виноват? Это твои проблемы чувачок и только твои!
208. herfis 281 10.01.18 13:50 Сейчас в теме
Само по себе прототипирование - вполне понятный инструмент.
Но не настолько уж бесплатный, как тут в статье описывается.
Настолько быстрое прототипирование и выкашивание его из продакшена, чтобы оно не отражалось на текущих планах, сроках и отчетах о проделанной работе (для соблюдения тезиса о приватности) выглядит довольно утопично.
207. kuzyara 742 10.01.18 13:34 Сейчас в теме
(41) Лекция 10: Расширенный анализ требований. Иллюстрированные сценарии и прототипы
https://www.intuit.ru/studies/courses/2188/174/lecture/4730
206. obsfromekb 16 27.12.17 09:44 Сейчас в теме
(188) Смотрите шире. Бухгалтер тратил лишнее рабочее время на определённые (важные) задачи, постоянно откладывая некоторые задачи с меньшим приоритетом (например сверка контрагентов по предыдущему юр. лицу). Теперь у бухгалтера появится время наконец-то закончить сверки, систематизировать первичку и выставить контрагенту 300 000 руб. просроченной дебиторской задолженности (ранее спорной). - как вариант
205. unpete 525 27.12.17 09:01 Сейчас в теме
(199)
посты с разбором реальных кейсов использования
Если это не противоречит формату инфостарта, можем вместе попросить (1c-intelligence) что-то написать на эту тему. Самой простой для понимания и близкой к специфике 1С, мне представляется тема Самообслуживания клиентов на примере микросервиса параметрических заказов
Кратко на живом примере:
- Есть завод по производству подоконников и нарезке их в размер
- Около 100 клиентов, до 3000 изделий в сутки, более 10 типов цен для разных групп контрагентов
- Строка заказа содержит такие атрибуты, как номенклатура, цвет, размеры, количество, ключ группировки (в какую пачку упаковывать), штрихкод
- Раньше, клиенты отправляли XLS-файлы специального формата, менеджеры загружали их в учетную систему, высылали назад клиентам счет с уточненными ценами и по факту готовности, файлы реализации - куча ручной работы, звонки по телефону и т.д.
- Сервис позволяет создавать заказы с одновременным расчетом спецификации и уточненной ценой, непосредственно из учетной системы клиента через HTTP API
- Кроме собственно создания заказов, API содержит Endpoints для диспетчеризации и получения из сервиса произвольных документов (оплаты, реализации), а так же, для настройки соответствий номенклатур, цветов и прочих справочников
- Ведется лог всех запросов и ответов сервиса. Клиент, через то же HTTP API имеет доступ ко всем записям этого лога
- При желании, создавать и отслеживать заказы можно в визуальном режиме через браузер
- При необходимости, в веб-приложении поддержан автономный режим, позволяющий создавать заказы при отсутствии доступа к интернету. Они отправятся на сервер, как только связь восстановится
karimov_m; +1 Ответить
204. karimov_m 26.12.17 17:49 Сейчас в теме
(203) ну это да. Хороших специалистов не много, как и хороших управленцев, который не будут ставить такие вопросы.
203. l1ike 26.12.17 15:25 Сейчас в теме
(202)
Так я то не против, но для этого сама организация, а потом и ее менеджмент должны дорасти, а пока в большинстве организаций все сводится к раздаче советов как работать подразделению, к которому советчик никакого отношения не имеет. Если в продажах сейчас более-менее уровень зрелости начинает подниматься, то в производстве вообще труба.
Я вот честно, не очень понимаю, как разговаривать с людьми, которые ставят вопросы не "где найти специалиста, который решит проблемы", а "где найти специалиста, готового работать за еду". Про то, как решать проблемы все все знают сами.
202. karimov_m 26.12.17 14:54 Сейчас в теме
(201) ну это уже стилистика. Если есть понимание, что задача решаема посредством увеличения мощности оборудования - ну так это результат анализа. Если есть понимание, что сколько бы ты не вкладывал в мощности - а толку нет (просто алгоритмический порог, который не дает идти дальше при любых бесконечных мощностях) - то стоит задумать о приобретении, все же, специалиста - который сможет решить проблемы (это станет очевидно при очередном вливании в "оборудование", на фоне нулевого выхлопа от этого).
Понимание (и человек, который это сможет озвучить) - необходимое успешное условие ведения работы на этом поле действий.
А уж по поводу "окраин" и "пром-зон" - ну как бы не в деревянном веке живем, есть удаленка, есть наконец, командировки и заказ специалиста на место на время проекта. Да дорого, да он не будет работать у вас вечно, но лучше так, чем очередные сливы денег на оборудование, которое будет упираться в 15% потолок "алгоритмов", которые на нем запускаются.
201. l1ike 26.12.17 14:15 Сейчас в теме
(200)
Это все оно конечно так, но на определенном этапе развития компании может быть выгоднее (а часто и просто понятнее для менеджемнта в части получения результата) вложиться в оборудование, а не в еще одного программиста 1с или аналитика. Да и не в каждом Мухосранске очередь толковых специалистов ждет шанса поработать на вашем супер-мега предприятии находящемся на самой окраине пром-зоны рядом с заводом по расфасовке серной кислоты.
200. karimov_m 26.12.17 13:03 Сейчас в теме
(198)Почему же. Законы рынка - примерно одинаковы как для маленьких компаний так и для больших холдингов. Да, подходы в управлении, планировании бизнеса - будут различаться. Но сам механизм (и основопологание - что сначала а что потом) - один и тот же: есть "бизнес заказ" (пусть даже в "гаражном производстве" он может называть по другому - не суть) который нагружает это производство/продажи - от него и пляшем. А уж размах "танца" - это уже менеджмент и управление, где IT - support структура, но ни как не "двигатель продаж" и рычаг увеличения дохода в 3 раза(в прямом понимании этого слова).
199. karimov_m 26.12.17 12:41 Сейчас в теме
(190) А еще - отлично бы тут сделать отдельные (новые) посты с разбором реальных кейсов использования. Т.е. - Задача - почему пришло понимание что использовать metadata выгодно на проекте, и разбор примера (или одного из блоков) как было использовано.
198. l1ike 26.12.17 10:05 Сейчас в теме
(146)
Товарищи, вы спорите о системах разного порядка. Одно дело когда это холдинг из 20 заводов и другое, когда это вчерашнее "гаражное производство", которое наконец накопило денег на дорогое оборудование. Управление системой должно соответствовать системе. Не нужно обобщать опыт полученный на определенном виде систем на все системы.
197. mixsture 26.12.17 10:05 Сейчас в теме
(180) увольнение это, конечно, самый наглядный способ - помню его из книг по ТОС. Но есть и другие. Достаточно на освободившееся время поставить другую работу.

В России ведь как заведено: к зубному врачу идут, когда уже зубы разваливаются. Примерно также и с автоматизацией - за нее берутся, когда сотрудники перегружены рутиной в разы. И поэтому, всегда есть некая очередь задач, до которых не доходят руки - они принесут пользу, но в обычной ситуации не до них.

Кроме того при увольнении сотрудника есть скрытый минус - мы теряем не просто набор профессиональных качеств, но еще за время работы у сотрудника накапливаются и знания о процессах в фирме, о продукции фирмы. Поэтому уволить сотрудника сегодня и нанять нового через 3 месяца (под сезон) - совсем не равноценная замена, несмотря на то, что проф качества у них могут быть идентичны.
196. 1c-intelligence 7979 25.12.17 23:52 Сейчас в теме
(189)
Есть у вас представление, как быстро и эффективно изучить эту технологию. В наличии программист 1С и специалист с незначительным опытом работы с JS.

Мы работаем в этом направлении. Пока эксперименты были на мне.
Завтра дам цифры, если не забуду.
195. 1c-intelligence 7979 25.12.17 23:49 Сейчас в теме
(190) даже страшно представить, какие требования к программисту 1С ты предъявляешь.
Ты описал программиста, который влюбится в метадату с первого взгляда, и начнет писать полезный код через день.
194. DmitrijT 25.12.17 14:24 Сейчас в теме
"Суррогат" появляется тогда когда нанят неправильный программист, если у Вас производство то нанимайте человека который хоть понимает что это такое и чем УПП отличается от УТ, много людей могут написать отчет продаж по менеджеру для УПП и только 1 из 20 (если не из 100) напишет его грамотно.
193. genayo 25.12.17 14:16 Сейчас в теме
(192) Хорошо, завязываю оффтоп :) если вы не против, будем писать в issues.
192. unpete 525 25.12.17 13:57 Сейчас в теме
(191)А стандартные issues чем плохи?
чтобы заинтересованным людям объяснять
Это - к Ивану. Я - костноязыкий.
191. genayo 25.12.17 13:45 Сейчас в теме
(190) Спасибо. Если сделаете на гитхабе подраздел типа "вопросы от чайников", было бы удобнее, чтобы основные разделы не захламлять. Живые задачи есть, пока нет понимания всех преимуществ технологии "на пальцах", чтобы заинтересованным людям объяснять.
190. unpete 525 25.12.17 13:30 Сейчас в теме
(189)Наши с (1c-intelligence) мнения по этому вопросу расходятся. Я считаю, что metadata понтравится веб-разработчику с большим опытом, который столкнулся с трудностями на предыдущих технологиях: сделал несколько проектов на java, php, ванильном js под node, микрософтовском .net, знает, как работает изнутри jquery, angular, vue, react. Важно уметь одинаково хорошо мыслить как в терминах sql, так и nosql map/reduce.
Изучать технологию без живой задачи, вряд ли имеет смысл. Если нужен совет, вопросы, наверное, лучше в github, но можно и сюда в отдельную ветку.
Согласитесь, тема слабо коррелирует с текстом статьи.
189. genayo 25.12.17 11:48 Сейчас в теме
(178) Допустим, мы приняли решение использовать вашу технологию. Есть у вас представление, как быстро и эффективно изучить эту технологию. В наличии программист 1С и специалист с незначительным опытом работы с JS.
188. dmt 48 25.12.17 10:52 Сейчас в теме
(177) Гм. Ну например бухгалтер делает некую задачу еженедельно.
Раньше тратил 4 час 1о минут в неделю.
После ускорения 10 минут в неделю.
Вроде бы появилось два человекодня в месяц, но денег-то в фирме больше не стало.
187. artempo 25.12.17 09:27 Сейчас в теме
(180)
Только увольнение может быть целью. В смысле сокращение.

Иван, а чего мелочиться?
У вас название статьи как раз подходящее!
Это же Спарта!!!
Давайте их сразу со скалы всех, дармоедов!
Или в лагеря строить БАМы.
186. pm74 123 25.12.17 07:52 Сейчас в теме
(179) давно присматриваюсь к вашей технологии, жаль времени и опыта программирования js не хватает. а 1с .. как была "программой для бухгалтеров", так ей и осталась.
185. unpete 525 24.12.17 19:21 Сейчас в теме
(183)
Чтобы не говорить на каждом углу [...] не корректно
Я, вроде не претендовал на объективность и ничего не заявлял ни на каких углах - просто отвечал на ваш вопрос - восстановите хронологию.

Могу себе позволить не беспокоиться о таких мелочах, как реальность и здравый смысл. Наверное, за жизнь успею сделать лишь малую часть задуманного, но вектор мне нравится и единомышленники начали появляться.
184. karimov_m 24.12.17 13:32 Сейчас в теме
(178)
Это понимают не все. Например, я - не понимаю.

Все же полезно это понимать) Например тут Чтобы не говорить на каждом углу - "1С закрытая система! Очевидно там баги внутри огогшные, поэтому они не опенсорс))"

Про то что необходимо для каждой задачи выбирать свой инструмент - речи не идет, это и 5-класснику понятно (он тоже не будет забивать гвоздь обмоткой изоленты). И тут действительно, нет смысла спору
183. karimov_m 24.12.17 13:23 Сейчас в теме
(182) Ну так у вас про- документный подход (про 1С) организации системы.
Это не плохо и не хорошо, это просто архитектурный подход. Говорить что это нормально, а все остальное "странный подход", не корреткно
182. unpete 525 24.12.17 07:55 Сейчас в теме
(181)
смотрю в сторону сенчи
Странное направление. На extjs, действительно, написана куча data-ориентированных интерфейсов, даже мой любимый proxmox использует extjs на своей вебморде, но их философия перпендикурярна нашим подходам. Metadata совсем про другое.
181. karimov_m 24.12.17 01:01 Сейчас в теме
(179) Занимательно, удачи вашему проекту!
а я вот смотрю в сторону Сенчи https://www.sencha.com
Тоже занимательная штука
180. 1c-intelligence 7979 23.12.17 20:32 Сейчас в теме
(176) мой опыт говорит, что экономия времени сотрудника за счет автоматизации приносит пользу бизнесу только в одном случае - если этого сотрудника уволить.

Иначе сколько не экономь время, он найдет чем его занять, и вот тогда от него станет вреда больше, чем пользы.

Ведь сотрудник, который переживает за свою необходимость в компании, какого только говна не придумает, чтобы свое существование оправдать.

Вот был пример со снабженцами. Автоматизировали все. На работу с системой они тратили 3 % времени, я специально проверял.

Была бизнесу польза? Ровно наоборот. Какого только бреда они не придумали, чтобы быть занятыми весь день. По кругу пошли, меняя концепции закупа: по плану, по ТОСу, по категориям, под заказ, опять по плану, опять по ТОСу, и так до бесконечности.

Только все устаканится, и встает вопрос о их (снабженцев) количестве, они снова инициирют изменения. А дальше по цепочке остальные - продавцы, производство, финансисты, юристы и т.д.

Только увольнение может быть целью. В смысле сокращение.
179. unpete 525 23.12.17 20:25 Сейчас в теме
(174)
почему смотрели на 1С, как платформу для потенциальной реализации
Потому, что задача, по сути - учетная. Похожа на то, для чего обычно используют 1С. Там есть параметрические спецификации, сложное ценообразование (действительно сложное - не как в УТ 11), диспетчеризация и подготовка производства (настоящее планирование - не как в ERP). Краткое описание есть здесь
178. unpete 525 23.12.17 20:15 Сейчас в теме
(173)
все же понимают, что это проприетарная система
Это понимают не все. Например, я - не понимаю.
Спорить нам не о чем. Если платформа 1С справляется с вашими задачами - я не против. Продолжайте эксплуатировать.
Metadata нужна, чтобы обеспечить высокую доступность данных, сохраняя при этом для программиста возможность оперировать высокоуровневыми объектами ala документ и справочник.
Сейчас, для обслуживания тысячи пользователей, metadat-е достаточно скромного сервера с одним сокетом.
Сейчас затеваем проект, у которого потенциально могут быть миллионы пользователей. Время покажет, что из этого получится.
177. mixsture 23.12.17 12:25 Сейчас в теме
Эта цифра дает еще одну пользу - она создает измеримый результат для собственника фирмы о том, чем занимается ИТ отдел, какие выгоды он производит в месяц.
А также неплохо показывает, когда чужие отделы просят автоматизацию, сколько в целом она принесет? очень важный вопрос, т.к. автоматизация на ограниченном участке всегда идет по снижающейся эффективности. Условно, 80% эффекта автоматизации мы можем сделать за 100 тыс руб, 90% за 200 тыс, 95% за 300 тыс руб, 98% за 400 тыс руб. На каком-то этапе отдел стоит перестать автоматизировать и заняться другими отделами :)
176. mixsture 23.12.17 12:15 Сейчас в теме
У меня, честно говоря, обратная статистика: относительно легко ее посчитать для маленьких задач, т.к. они почти всегда вокруг ускорения работы сотрудника. И там легко перейти на часы в месяц и его зарплату - собственно, это и есть максимальный потенциал. А вот с большими проектами как раз могут быть проблемы, т.к. они часто добавляют работу одним отделам, сокращают другим, а еще в них появляются мифические менеджерские фразы "улучшение конкурентных преимуществ, аналитики", которые, к сожалению, редко продуманы и оценены и поэтому редко что-то реально дают фирме.
Но, имхо, в любом случае эта цифра, хоть и приблизительная - очень и очень полезна для управления фирмы. Так как заставляет задумываться менеджмент об общей пользе для фирмы, а чаще всего менеджмент думает только о локальной оптимизации на его участке работы и поэтому часто появляются проекты, результатом которых является лишь перенос работы с одного отдела на другой и ничего более.

И эта идея, кстати, соответствует вашей концепции - завершить неудачный проект как можно раньше. Ведь по сути, она добавляет предварительную проверку задаче, т.е. является частным случаем прототипа.
175. 1c-intelligence 7979 22.12.17 23:51 Сейчас в теме
(165)
в заявке в ит отдел по доработке чего-либо появляется поле "ожидаемая прибыль для фирмы (руб)". Это позволяет сортировать задачи как раз по положительному эффекту на бизнес и сравнивать их с затратами. Это позволяет сильно затруднить прохождение суррогатов.


Я пробовал - никто никогда эту цифру не посчитает. И это все понимают. И опять виноват программист.
Ну уровне проектов еще можно прикинуть, на уровне заявок - нет.
Ну и всегда можно свалить на реализацию, т.е. опять же на программиста.
174. karimov_m 22.12.17 14:09 Сейчас в теме
(163) очень интересно в краткой форме услышать вводный по этой задаче. в чем именно проект и, самое главное, почему после ее изучения вами, в первую очередь вы смотрели на 1С, как платформу для потенциальной ее реализации (вы ведь начали их чего "понимать", что все не так в 1с, для этой задачи..)
173. karimov_m 22.12.17 13:57 Сейчас в теме
(162)
Понятно.
Ну по поводу "закрытый фреймворк" - все же понимают, что это проприетарная система. Есть патенты и тп.
И, конечно же, некорректно рассуждать в таком ключе - "если ситсема закрыта - значит говнокод, поэтому мы ничего никому не покажем", одно не следует из другого.
- А в чем плох велосипед ? Не понимаю вот часто, почему к "Велосипедам" такое отношение. Поверьте - если "велосипед" едет и делают свою функцию хорошо и на большом отрезке времени - это лучше чем может быть. Например есть алгоритм поиска пути (Дейкстры + есть более эффективный A*) - вы будете писать свой, только из-за того что это уже "чей-то велосипед"? Не уверен, что именно так, но скорее всего в 1С используют подход "создания байт-кода" для выполнения его платформой. Это не всегда плохо (а в случае 1С - практически единственный путь - вспомним SAP, Saleforce). Если абстрагироваться от деталей, то тоже и в Java и в .NET
Ну и конечно же не понятно - в чем именно были бы они эффективнее, если предоставили для разработки один из существующих языков высокого уровня.. Тут всё о пороге входа и бизнес-ориентированному программированию.
- Отсутствие метаданных на клиенте и в целом странный подход к рендерингу клиентского интерфейса
- Откровенные ляпы в объектной модели, например, искусственное деление на обычные и системные перечисления

Эм.. тут не понял. Какие метаданные вам нахватает на клиенте? В чем именно "странность" рендеринга клиентского интерфейса? (опустим технические детали или ошибки конкретной версии платформы) В архитектурном плане - в чем именно странность? (подсказка - помним про трехуровневую модель).
По поводу разных видов перечислений - тут все просто. Есть системные, которые определяются в платформе (для передачи параметров в функции и т.п. например определение как именно будет выглядеть диалог открытия файла) - нет смысла, конечно же, держать это все в ветке Конфигурации. Тем не менее, платформа "дает возможность" определять и свои собственные перечисления. Предметно-ориентированные.
Надеюсь вы воспримите мои аргументы как здоровую критику на ваш ответ)
172. friend0 22.12.17 13:26 Сейчас в теме
(171)Да вообще-то про уровень Газпрома речи не шло. И про франчеподобную команду тоже:
Представьте исходную ситуацию. К фикси-программисту 1С подходит человек – пользователь системы, он же – руководитель некоего подразделения.


Про то что знаете лучше всех речи не было. Но шире всех почти всегда. Потому что люди заняты делами своего отдела, а не других. Естественно, если вдруг на предприятии появляется человек, работа которого заключается во вникании в деятельность каждого подразделения, документирование по ISO, оптимизация процессов и прочее - тогда, конечно, он будет более компетентен. Только речь-то не о таких компаниях.
171. ifilll 21.12.17 15:05 Сейчас в теме
(170) Не сочтите за оскорбление, но мне сдается что люди рассуждающие в подобном ключе, не работали в команде, не работали на крупных предприятиях, и плохо понимают по настоящему что такое "система".

Уверенность в том что вы знаете лучше всех опасна по природе своей, мания величия какая то.
А если вы что то действительно знаете почему вы работаете программистом, работайте в том направлении в котором вы лучше всего разобрались, ведь на это вы использовали значительное время, которое не использовали что бы стать лучшим программистом.

Возможно это не очевидно, но там где мы с вами находимся, катастрофически не хватает специалистов знающих свое дело досконально, не хватает программистов, инженеров, смешно сказать но даже бухгалтеров. Быть этим самым программистом который во всем разобрался и есть главный и печальный суррогат, почему это не очевидно я не знаю.
Gluk_1C; корум; artempo; +3 Ответить 1
170. friend0 21.12.17 13:21 Сейчас в теме
(168)А никто и не говорил про априорные знания. И отличия как раз в том и состоят - решаешь ли ты задачу исходя только из тех знаний что тебе предоставляет заказчик (а ему будет лень к задаче длиной в одно предложение писать сопроводительный текст на 30 страниц, и другие отделы для него либо неинтересны либо враги) или ты самостоятельно в течение нескольких месяцев/лет вникаешь в то что происходит вокруг. Во втором случае можно будет смотреть на задачу не глазами заказчика, а шире с позиции всех действующих процессов компании.

А драгоценные ресурсы это что? Время программиста, который делает суррогаты? ИМХО лучше "потерять" день и сделать одно дело хорошо, чем быстренько сделать два дела, от которых больше вреда чем пользы.
169. Drak0n 165 21.12.17 12:14 Сейчас в теме
(167)В том то и дело, что у бухгалтера будет положение о премирование, заверенное руководителем, а у рабочего план за подписью нач. производства. Т.е. они действуют в рамках спущенных им компетенций. У программистов обычно (исключительно по личному опыту) эти "рамки" отсутствуют или они их ставят себе сами.
А кто может поставить четкое задание программисту? Только другой программист более высокого ранга

Так я об этом же. Кто может оценить "качество" поставленной бухгалтером задачи? Программист? Нет - только другой бухгалтер более высокого ранга. Поэтому я и считаю нормой вынесение подобных вопросов на уровень тех специалистов которые имеют знания и опыт в этих смежных областях (условно "управленцы")... Ну или если таких сотрудников нет - по крайней мере обсуждение задания между поставившим и исполнителем.
168. ifilll 21.12.17 09:18 Сейчас в теме
(166)
"Сколько" нужно сделать деталей станочнику - не задача программиста. Это задача технолога, продажников, директора производства, бригадира и прочих лиц.
- правильно, более того постановщиком задачи и "кондуктором" информации должен быть постановщик, программист должен получить исчерпывающее ТЗ, со всей вводной информацией, иначе он много времени потратит на то что бы постоять у станка и т.д., затраты драгоценных ресурсов это печально.

(166)
Задача программиста знать на основе какой входной информации они будут принимать решения, обеспечить чтобы она удобно заполнялась, была в удобном доступе и максимально автоматически считалась.
- неправильно, вы не можете знать то что не знаете, это нужно узнать совместно с постановщиком задачи, система априори не содержит исчерпывающей информации.

Посыл Ивана Б. в том что бы знать это лучше чем люди которые эти задачи ставят, а это в принципе не возможно. По крайней мере меня он не убедил.
167. &rew 7 21.12.17 07:34 Сейчас в теме
(152)Ох, в "подкидного" играем походу.
Давайте логику немного используем, без делений на достойных и недостойных.
Вот средняя контора в которой 1С прогер один. Без ИТ директора. Главбух, нач продаванов, или директор говорит, Надо все затраты посчитать и раскидать на единицу товара, вплоть до болтика, чтобы понять где можно оптимизировать затраты (с делением по статьям). Задача достаточно тривиальная, ничего "военного" в ней нет, программист начинает делать. А делать как? А вникать в процесс точно так же, как вникает главбух + нач продаванов + нач производства + нач склада (вместе взятые). Теперь скажите - это чей уровень?

Или например, есть ИТ директор который ТЗ ставит. А что такое ТЗ? Это четкое задание программисту. А кто может поставить четкое задание программисту? Только другой программист более высокого ранга, который сам был когда-то обычным программистом. Или например например бывший админ, который коллегиально с тем же программистом вырабатывают ТЗ. Тогда программист опять же вникает в (см. выше).

Представьте себе, например, бухгалтера самолично решающего кому начислять премию, а кому нет... или рабочего самостоятельно выбирающего какую деталь ему производить...


Если бухгалтер на предприятии один, сколько угодно такого может быть, ну а с рабочим, тоже вполне может быть, если у него есть некий план по производству деталей, может и сам решать, что производить в данный момент времени, например в зависимости от настроек производственного оборудования. Все зависит от структуры предприятия и ее иерархии, Вам ли не знать. Или ...?
166. friend0 20.12.17 23:26 Сейчас в теме
(164)"Сколько" нужно сделать деталей станочнику - не задача программиста. Это задача технолога, продажников, директора производства, бригадира и прочих лиц. Задача программиста знать на основе какой входной информации они будут принимать решения, обеспечить чтобы она удобно заполнялась, была в удобном доступе и максимально автоматически считалась. Знать и обеспечить удобный доступ станочнику к информации что и когда он должен сделать, откуда взять какой материал, куда положить готовое изделие, как обеспечить его идентификацию и отражение всего этого в информационной системе.

"Информационная система" имеется ввиду в широком смысле - это может быть и устное получение информации от бригадира и устное сообщение о результате ему же. Это может быть и взять из кучи с ярлыком "1" и положить в кучу с ярлыком "2", которые раз в месяц инспектирует бригадир, а может быть и уникальный штрихкод вешаемый на уникальную детальку с параллельным заполнением в БД 145 параметров этой уникальной детальки, которые кроме станочника никто не знает.

В жизни, конечно, всякие извращения бывают и возможно начальство потребует от программиста 1С рассчитать нормочасы для изготовления детали №2 на неизвестно каком станке из сами придумайте чего и где это подешевле купить, кому ее продать, какие разрешения в гос органах оформить, как организовать рекламную кампанию - оно конечно интересно разобраться, но как-то сомнительно работать с такими неадекватами.
165. mixsture 20.12.17 21:39 Сейчас в теме
Статья классная. Тест идеи на прототипе - тоже супер. А вот управленческие методы мне не нравятся, я бы очень ограниченно их применял.

Вы пытаетесь решить проблему суррогатов в 1с, но при этом создаете управленческий суррогат. По сути, создаете фирму внутри фирмы, создавая негласные связи, процессы, договоренности.

У этого есть свои негативные стороны:
1) с точки зрения фирмы
а) для собственника/генерального созданное вами управленческое явление - это черный ящик. Для них не очевидно, когда он начнет работать и в какую сторону. Поэтому в случае проблем чаще всего виноватым будете вы :)
б) если ваш проект саботируют - это тоже результат. И показывает нерешенные проблемы в управлении довольно высокого уровня. Ваш метод позволяет их обойти/спрятать под ковер, но проблемы от этого не исчезнут.

2) с точки зрения рисков проекта
а) вы убрали саботаж снижением страха потерять репутацию - отлично. Но при снижении публичности пытаетесь минимально вовлекать или вообще не вовлекать других зависимых лиц. А это в свою очередь легко может привести к пропуску, например, факта, что ваше решение создаст дополнительную нагрузку на отдел, где физически сейчас невозможно выполнить больше работы. Вы рискуете сделать узкое место в фирме.
б) создание преимуществ одному отделу часто отражается повышением затрат в другом отделе (например, заполнять больше полей). Учитывая, что почти вся зарплата фиксированная - для сотрудников "неудачного" отдела вы пришли, чтобы добавить им работу и заставить работать больше. И убедить их в красоте идеи или общего результата вам будет тяжело или даже невозможно. Такого класса проблемы и решаются с помощью структуры управления фирмой. А тут мы получаем тоже риск саботажа.
---
Для исключения суррогатов из 1с, да и не только, мне очень нравится такая идея - в заявке в ит отдел по доработке чего-либо появляется поле "ожидаемая прибыль для фирмы (руб)". Это позволяет сортировать задачи как раз по положительному эффекту на бизнес и сравнивать их с затратами. Это позволяет сильно затруднить прохождение суррогатов.
164. ifilll 20.12.17 16:56 Сейчас в теме
(160) Одно дело когда ставится задача отразить количество сделанного станочником, другое дело когда нужно сказать сколько нужно сделать станочнику. Вы как задачу решать будете?
163. unpete 525 20.12.17 16:33 Сейчас в теме
(156)
до крайности еще не доходило
У нас выбора не было. Замахнулись на специфическую задачу, которая на стандартной платформе 1С ну никак не решалась. Пришлось делать свою платформу. А потом оказалось, что под эту платформу много других нерешенных задач - голубой океан.
162. unpete 525 20.12.17 16:29 Сейчас в теме
(156) Тема для многомесячной дискусии. Основные тезисы:
- Черный ящик. 1С - полностью закрытый фреймворк. Хороший код нет смысла скрывать. Его публикуют под свободной лицензией, чтобы люди могли любоваться, как картинами в Эрмитаже. Г*внокод обычно прячут
- Велосипеды. Язык, стековая машина, движок данных собственной разработки. Imho, надстройки над стандартными библиотеками и расширение стандартного языка (не важно какого, java, js, c#), были бы эффективнее
- Отсутствие метаданных на клиенте и в целом странный подход к рендерингу клиентского интерфейса
- Откровенные ляпы в объектной модели, например, искусственное деление на обычные и системные перечисления
161. friend0 20.12.17 16:03 Сейчас в теме
В целом про непубличность согласен, но вот "fail fast" как-то сомнительно. Проще тет-а-тет понять нужды заказчика (вряд ли он будет приходить если ему ничего не надо) и превратить озвученный суррогат в полезную фичу (прежде всего в голове). А вот "быстро слепленный" проект имхо всегда будет выглядеть как фейл - бантики наше все.
160. friend0 20.12.17 15:47 Сейчас в теме
(135)Необязательно (хоть и желательно) работать на конкретном месте для понимания "системообразующих" принципов. Необязательно знать сопромат и технологию обработки металла, чтобы "видеть" работу станочника в потоках (хотя бы информационных) предприятия. Необязательно знать какие именно коммуникационные техники используют коммерсанты, чтобы втюхать продукт, достаточно понимать что к ним в черный ящик должно входить, что выходить и какие индикаторы отражающие работу этого ящика должны быть видны. Конечно, возможно придется углубляться и внутрь, но маловероятно и почему бы и нет. Программисты не могут делать любую работу, но уметь ее отражать в информационной системе обязаны.
159. friend0 20.12.17 15:05 Сейчас в теме
(122)
Только у меня постоянно вертится такой вопрос - а ПОЧЕМУ я должен думать за других? Почему должен уберегать их от ошибок?

Это примерно как с замусоренным пляжем. Почему другие мусорят, а ты не должен? Или может даже должен убирать их мусор? Нет - не должен. Можешь даже своего докинуть и наслаждаться "природой".
158. genayo 20.12.17 10:58 Сейчас в теме
(153) В нормальной компании главбух занимается регламентированным учетом, и придумывает, как всякие "серые" схемы по этому регламентированному учету провести, не более. А бизнес-процессами обычно несколько другие люди рулят.
157. pm74 123 20.12.17 10:52 Сейчас в теме
(153) наш главбух который как бэ
заинтересован ..
- основной генератор суррогатов
из последнего https://forum.infostart.ru/forum8/topic183411/
156. karimov_m 20.12.17 10:49 Сейчас в теме
(113) Добрый день!
А можно увидеть в чем именно разногласия по "базовым архитектурным вопросам"?
Действительно интересно (у меня тоже есть мысли что могло бы быть лучше в 1С, но до крайности "писать свою 1С" еще не доходило).

Ну и конечно же, мы все же понимаем, что каждый продукт заточен под решения определенного (но не всего возможного) круга задач.
155. 7OH 33 20.12.17 10:41 Сейчас в теме
Если на публику не хочет играть программист и заворачивает просьбу, то на публику начинает играть "заказчик".
И играть, заметьте, с намного большим пафосом, чем это сделал бы программист.
Если речь идёт про ФИКСИ.
154. hornet_X 1 20.12.17 10:11 Сейчас в теме
(58) А еще есть такие бизнес аналитики (руководители проектов) со стороны клиента заказчика, функция которых сводится к КонтролЦКонтролВ. И это печально...
153. David_1C 20.12.17 10:08 Сейчас в теме
Все просто. Меняйте компанию-болото на нормальную! Ибо в нормальной компании в первую очередь главбух и директор заинтересованы в том, чтобы в конце месяца/квартала у них сошелся дебет с кредитом и они нормально отчитались перед налоговой, так как это уголовная ответственность, а не чтобы из-за тупого дурачка менеджера, который ни черта не понимает в программе, развалилась вся база, потому что ему захотелось суррогата, так как он думает что программа не может, не умеет. Я был свидетелем, когда главбух раздавала прилюдно "люлей" целому отделу маркетинга, а потом отделу финансов, при этом она чуть ли не с мечом рубила горячие головушки! А еще был случай, когда мне сразу же при устройстве в одну компанию пришли и сказали: понимаешь, у нас тут много долбае..., которые не умеют и не знают как работать в 1С и вечно чего-то хотят, но что делать, специалистов найти трудно, даже на хорошую з\п, так как их мало, поэтому приходится брать и учить "таких", поэтому все новые "хотелки" только через главбуха, аналитика и вплоть до директора, а если тебе начинают предъявлять претензии сразу можешь посылать громко и подальше! Еще хочу добавить, чтобы не быть дураком в проблемных компаниях, очень помогают сертификаты 1С. У меня есть сертификат, а у тебя тупой Вася менеджер нету, значит дурак ты, а не я.
152. Drak0n 165 20.12.17 09:27 Сейчас в теме
Только вот ИТ директор - это одна из мастей айтишника

(111) Круче этих в любых сферах бизнеса разбираются разве что HRовцы.
Вот как раз близость программистов к управленцам внушает данным специалистам иллюзию собственной значимости... И вместо выполнения своей непосредственной работы начинаются попытки принятия управленческих решений и единоличная оценка заданий на "достойные" и "недостойные".
Представьте себе, например, бухгалтера самолично решающего кому начислять премию, а кому нет... или рабочего самостоятельно выбирающего какую деталь ему производить...
klaus38; IgorS; sergelemon; Gluk_1C; +4 Ответить 1
151. rusinfostart 20.12.17 09:21 Сейчас в теме
Ништяк спасибо автору, суть не прочитал, мне уже хватило ваших вариантов "Вариантов развития событий много" для того чтобы шлак не создавать!
150. DrAku1a 1302 20.12.17 09:21 Сейчас в теме
(63) Просто "Путь программиста"
149. Synoecium 628 20.12.17 09:15 Сейчас в теме
(117) а вам не приходило в голову, что вы тоже можете заблуждаться и это временный этап - желание учить программистов 1с как надо делать? И еще, ваше правильное решение может показаться другому специалисту субъективно искаженным суррогатом, что вы в таком случае будете делать? Или пройдет время и окажется, что ваше решение было красивым, но тот "суррогат", который предлагали изначально сработал бы лучше, просто у вас было мало сведений во время принятия решений?
Gluk_1C; David_1C; +2 Ответить
148. gull22 86 20.12.17 09:01 Сейчас в теме
Автору поклон, за литературный стиль.
147. 1c-intelligence 7979 19.12.17 14:01 Сейчас в теме
(144)
Такие люди вырастают из разных людей (пардонте за каламбур), и совсем не обязательно из 1с программистов, а я бы сказал что совсем обязательно, но это ИМХО


вы смотрите на этот процесс пассивно, как на естественную эволюцию. Да, иногда прорастают и слесари, видел такие примеры.
Почему программисты, и почему выращивать - расскажу в другой раз.
146. 1c-intelligence 7979 19.12.17 13:59 Сейчас в теме
145. karimov_m 19.12.17 13:52 Сейчас в теме
(141)И? В чем ошибка то?)
Это "у вас в фирмах" много потерь, просто ваши БП не оптимизированы или не умеют быстро реагировать на изменения рынка.
Именно так и формулируется ключевая ошибка!

Хочешь зарабатывать больше, ищи ответ в клиентах, рынках, точках, управленческих решениях, и т.д.
Вы, как программист, понимаете, что все это - элементы бизнес-системы. Важные, бесспорно. Но не единственные. И далеко - ОЧЕНЬ ДАЛЕКО - не всегда главные.

Если бизнес - делает продажи - самое важное для него - это рынок, его потребности и механизмы, посредством которых услуга/товар будут поставляться на этот рынок максимально эффективно и с минимальными издержками для бизнеса.

Если у вас (фирмы, бизнеса) - есть проблемы с обеспечением обработки "спроса".. ну.. что тут сказать. Ищите специалистов, которые выстроят вам эти процессы, иначе ребята, вы теряете деньги, пока думаете "кто будет это реализовывать", "а почему я, программист, делаю это так а надо вот так", в то время, когда ваши конкуренты - имеют команду, где ставятся четкие задачи, есть рук.проекта, аналитики и программисты, которые "реально программируют, что сказали" и не тратят время на лишние задачи/размышления. А внедряют оптимизационные механизмы, которые обеспечивают потребности в обработке спроса и задачам бизнеса..
144. ifilll 19.12.17 13:50 Сейчас в теме
(139) Именно тех парней отправляют, вы ошибаетесь в парадигме.

Вы в своих рассказах описываете не программиста вовсе, это визионер, оптимизатор, директор по развитию или что то подобное. Такие люди вырастают из разных людей (пардонте за каламбур), и совсем не обязательно из 1с программистов, а я бы сказал что совсем обязательно, но это ИМХО.

Конечно ваша точка зрения имеет место быть, но посыл нужно переработать, сделать универсальным для всех людей, что бы выхватить жемчужины ))
И главное не ставить акцент на программистах.

Станете в строй с модными Кови, Карнеги и иже с ними.
корум; +1 Ответить 1
143. 1c-intelligence 7979 19.12.17 13:47 Сейчас в теме
(142) ладно, на том и остановимся.
karimov_m; +1 Ответить
142. karimov_m 19.12.17 13:41 Сейчас в теме
(138) конечно не о чем)
Ведь мы пришли к тому, что у вас (и там где вы работаете(ли)) люди занимаются не своим делом =) От этого и постоянный pain и не понимание, от чего же ничего не получается=)
Иван, вот вижу, Вы грамотный человек, возможно специалист, имеете кругозор и постоянно его расширяете, это хорошо.
Но проскакивают у вас нет-нет, очевидные фейлы (например как ваше вышестоящее утверждение: что вы не любите чтобы каждый занимался своим делом), возможно это от нехвтатки опыта на реальных проектах, то что вы сами строите или пытаетесь выстроить взаимоотношения между бизнесом и заказчиком - это хорошо, инициативы в этом направлении нужны. Но пропагандировать путь - "каждый может заниматься всем" - это очень неверный подход. Может то может, но вот эффект такого взаимодействия - будет стремиться к 0.
Нужен пример структуры, где цена такого подхода - смерть? Армия
Gluk_1C; David_1C; artempo; +3 Ответить 1
141. 1c-intelligence 7979 19.12.17 13:36 Сейчас в теме
(140) вот, вот, именно то что нужно! Именно так и формулируется ключевая ошибка!

Хочешь зарабатывать больше, ищи ответ в клиентах, рынках, точках, управленческих решениях, и т.д.

Вы, как программист, понимаете, что все это - элементы бизнес-системы. Важные, бесспорно. Но не единственные. И далеко - ОЧЕНЬ ДАЛЕКО - не всегда главные.

Намного больше потерь и, соответственно, возможностей скрыто внутри компании, т.е. бизнес-системы, в ее производительности.

На рынки, клиенты, точки и т.д. - дохера специалистов. Пусть они этим и занимаются. Но их задача - лишь обеспечить бизнес-систему достаточным объемом спроса.

А уж как будет обрабатываться спрос - дело бизнес-системы. Убираем слово "бизнес", остается система. А система - это для программиста.

И нихрена там сложного нет.
140. karimov_m 19.12.17 13:31 Сейчас в теме
(137) Потому что это не требования к IT проектам. Это требования уровня - "хочу 100000 лямов к после завтра!", примерно такой вот уровень.
Вы на какой позиции в компании стоите вообще?
Решение такой задачи - это во первых - вопрос определения основного направления бизнеса. Если это продажники - то очевидное решение - это увеличить маржу/доход. Это легко решается увлечением оборотов - (новые точки, привлечение клиентов, новые рынки сбыта и тп.)
Но поймите же (как это вам не очевидно то?) - есть простые законы, есть наконец-то "емкость рынка", это все поле игры - не IT.
Если есть такой потенциал (увеличить в 3 раза доход в течении 3 лет) - то это решается экономическими и торговыми рычагами у управленческих решениях. Чтобы "обеспечить" такое "поведение системы" - можно уже предлагать конкретные технологические подходы, который позволят реализовать этот потенциал. Но опять же, они должны быть обеспечены "бизнес заказом" в ктором есть план и понимание, что это вообще реализуемо, а то снова получиться что будет "pain" у вас.
Liris; Сурикат; Gluk_1C; David_1C; artempo; +5 Ответить 1
139. 1c-intelligence 7979 19.12.17 13:27 Сейчас в теме
(135)
Что в той самой работе разбираться, её поработать нужно, поработать бухгалтером, экономистом, технологом, ПДО'шником и т. д.


ДА!

Что в этом удивительного-то? Это мировая практика, и уже давно. Правда, применяется для менеджеров - заставляют посидеть, поработать, прям руками, на каждом значимом рабочем месте.

Эта рекомендация дается в книгах, которые программисты упорно не хотят читать.

Вот пример, как к этому с другой стороны заходят: https://staff.wikireading.ru/9818

Кусочек текста: "Никогда никого не нанимайте на работу, пока сами не попробуете ее выполнить. Так вы сумеете понять характер этой работы, уясните, как должен выглядеть ее хороший результат, сможете составить ее реалистичное описание и вопросы".

Но эти ребята, которые так советуют, совершают одну существенную ошибку - не тех парней отправляют "везде посидеть".
138. 1c-intelligence 7979 19.12.17 13:22 Сейчас в теме
(136)
просто я люблю, когда каждый занимается своим делом

ок, ну ладно :)
А я не люблю.
Тогда и спорить не о чем :)
137. 1c-intelligence 7979 19.12.17 13:21 Сейчас в теме
(134)
Требования - это условие/способность, необходимая заказчику, чтобы решить его проблему и достигнуть цели


ну, а в чем противоречие?

Смотрите.

Заказчик - есть. Собственник или директор.
Цель - есть. Хочет иметь определенный доход. Ну, они так любят больше выражаться - через доход или прибыль за период. Например, 100 млн. в год.

Теперь что надо заказчику? То, что вы пишете - условие/способность. Классная формулировка. Особенно способность.

Ему нужно, чтобы его компания приобрела способность зарабатывать 100 млн в год. Ну, если точнее, развила свою способность зарабатывать с 30 до 100 млн. в год.

Способность - это свойство системы, коей является компания. Эта способность - типа как метод объекта. У него есть пропускная способность, или лучше назвать ее "скорость". Скорость генерации дохода или прибыли.

Итоговая формулировка - заказчик хочет, чтобы его бизнес-система увеличила скорость генерации дохода втрое.

Чем не требование? И почему оно не для программиста?

Вот система, вот цифры, вот вход, вот выход, вот потери, вот лишняя нагрузка, вот простои, вот свойства, вот методы.
136. karimov_m 19.12.17 13:17 Сейчас в теме
(133) ну почему же, просто я люблю, когда каждый занимается своим делом. при этом я не исключаю рост од одного к другому. Но это во времени. А в рамках проекта - извольте выполнять то, что говориться и на той позиции, которой стоите. А иначе и будет получаться "рыба, рак и щука", "пенты разъезжаются", каждый "задумчивый такой", что начинает дискутировать о том, как правильно надо))
Нафиг мне нужны такие на проекте, у меня есть задача, и есть четкое понимание как ее решать (коллективное мнение специалистов!) с учетом, всех требований, сроков и бюджета. Разбиваем на вехи/этапы/спринты не важно - выделяем под задачи ресурсы (программисты, аналитики) - решаем, проверяем, тестируем, закрываем идем далее.
Gluk_1C; David_1C; +2 Ответить 1
135. ifilll 19.12.17 13:16 Сейчас в теме
(116) Ну это фантастика какая то..

Что в той самой работе разбираться, её поработать нужно, поработать бухгалтером, экономистом, технологом, ПДО'шником и т. д.
Где на это все время найти, кто готов за это все платить? Если не понимать её досконально, работу эту, то будут суррогаты.

В моей личной практике "Поделия" (они же суррогаты по вашему) творят люди которые думаю что они во всем разобрались, по мне так лучше бы программисты программированием занимались, не хватает их уж очень, нормальных.

Вы Иван конечно можете апеллировать к тому что все можно разобрать логикой, и я даже соглашусь, поверхностно конечно можно, как один бородатый ученый мужик сказал "Программисты любую работу могут делать", только это бредни все. Если человек приходит к программисту и говорит помоги разобраться, то это уже печально, делу такой человек опасен просто.
Gluk_1C; David_1C; karimov_m; +3 Ответить 2
134. karimov_m 19.12.17 13:12 Сейчас в теме
(132)
Это не требования же)
И вообще, забавные у вас IT-проекты - увеличить генерацию прибыли компании. Это задачи уровня директоров (производства, продаж и тп).
необходимо принимать "управленческие" решения для достижения этих "показателей". Требования тут ни при чем, это просто "хотелки".
Если на вас делегируют "такие" задачи в компании.. ну у меня больше вопросов тогда нет.

Требования - это условие/способность, необходимая заказчику, чтобы решить его проблему и достигнуть цели
133. 1c-intelligence 7979 19.12.17 13:00 Сейчас в теме
(130)
что должен знать системный аналитик или возьмем более высший порядок - DevOps

ох уж любите вы ярлыки :)
132. 1c-intelligence 7979 19.12.17 12:58 Сейчас в теме
(131)
Если вы "так" относитесь к "требованиям по проекту", то мне становиться совсем грустно.


Вот примеры требований по проекту, с которыми я работаю:
1. Увеличить скорость генерации прибыли компании за 3 года втрое;
2. Увеличить "пассивную" прибыль компании в 4 раза за 2 года.

Это - полная и всеобъемлющая формулировка. Больше в документе "Требования по проекту" ничего нет.

К таким требованиям я отношусь хорошо.
131. karimov_m 19.12.17 12:46 Сейчас в теме
(129)
Вернуться к чему?)) К вашему не решающему проблем рецепту?) Спасибо, не надо)
У меня, думаю, хватает компетенций, чтобы понимать как вообще не заходить в такие надуманные проблемы.
не хотите попробовать лучше и больше - ок, руководствуйтесь фразами "Но так не бывает в жизни", "требования должны быть стабильны", "Необходимо уметь общаться с бизнесом", "один человек не в состоянии объять необъятное".

Ох лукавите, Иван ) Если вы "так" относитесь к "требованиям по проекту", то мне становиться совсем грустно.
Где взаимосвязь между моей фразой и "не хотите пробовать лучше и больше"??
Конечно это мой выбор, потому что я понимаю о чем говорю. И это практика многих компаний, где есть грамотно выстроенный процесс принятия решений и переход к выполнению задачи. У вас же опыт, судя по вашим статьям, в основном, проблемный - вам некомфортно, вы понимаете что как-то не так все устроено. Знаете от чего так? От того, что я писал выше.
Чтобы понять проблему - надо с ней столкнуться или знать о ней со стороны. Я не говорю что проблем не бывает в целом. Но повторюсь: грамотная расстановка "игроков проекта" и команда, настроенная на результат, которая выполняет задачи (а не сидит и думает, почему я это делаю, ведь это не так должно быть!!) - это решение 90% всех проблем.
Просто мало кто хочет тратиться на все это (системные аналитики, БА, менеджеры проектов) все хотят одного человека который будет решать все и за всех. Так не бывает, это переход в "любительскую лигу", на что есть свое давно подмеченное высказывание:
Если вы думаете, что профессионал стоит слишком дорого, попробуйте нанять любителя..
Gluk_1C; David_1C; +2 Ответить 1
130. karimov_m 19.12.17 12:32 Сейчас в теме
(116) это в принципе (относительно реализаций проектов) - то, что должен знать системный аналитик или возьмем более высший порядок - DevOps
Каким бы ты не был "специалистом всех наук" - ты не сможешь быть на столько глубоким, чтобы знать деталей области. А в нашем деле - детали - это очень важно, от одного неправильного выбора подхода или технологии - может зависеть успех проекта в целом (либо это будет тормозить выполнение проекта).
Понимать принципы, алгоритмы и технологии - это подразумевается по "умолчанию" для всех IT-ников. Иначе зачем они в IT, если могут делать все только по инструкции и по шагам? Так и роботы могут это делать.
Gluk_1C; David_1C; +2 Ответить 1
129. 1c-intelligence 7979 19.12.17 12:17 Сейчас в теме
(128) вот об этом я и говорил - не поверите.

Выбор-то за вами. Все нравится, всем довольны, не хотите попробовать лучше и больше - ок, руководствуйтесь фразами "Но так не бывает в жизни", "требования должны быть стабильны", "Необходимо уметь общаться с бизнесом", "один человек не в состоянии объять необъятное".

Все эти фразы - не объективная реальность, а ваш выбор.

Ни в коем случае не убеждаю вас. Есть люди, которые поняли эту проблемы - у них появился pain, и им нужно решение. Если у вас pain нет - ок, вернетесь, когда он настанет.
128. karimov_m 19.12.17 12:08 Сейчас в теме
(121) Какая то надуманная у вас (вот откровенно, просто анализирую) "ключевость". Вы зачем-то подтягиваете понятие "устаревания" принятого ранее решения по процессу/разработки во время самого процессе. Но так не бывает в жизни (или это очень неправильный архитектурно проект, который создается без разбора будущих потребностей, нагрузок и тп.). Типа сняли "снапшот" и все, в рамках него работаем - да именно так! Потому что требования должны быть стабильны а не превращаться в макаронину) Вам знакомо выражение: Требования подобно воде, на них удобнее опираться, когда они заморожены. Это в защиту "снепшотности" проекта. Тем не менее, никто не исключает итеративное развитие и тп.
Далее у вас настает какой-то процесс "разбалансировки" триад и пентад. Ну честное слово.. ну о какой разбалансировки может иди речь, когда есть задача, она проанализирована на Бизнес уровне, по ней даны Технические и системные профили (на чем, какими инструментами реализовывать), учтены риски и требования к системе. Все. Заморозили. Делаем быстро пилот, проверяем показатели - далее в разработку по четкому ТЗ с итеративным тестированием компонентов (этапы/вехи проекта можно показывать бизнесу и сдавать на приемку).
Необходимо уметь общаться с бизнесом и утверждать (замораживать) все требования, а если у него (бизнеса) приходит понимание что что-то упустили - принимать это и уметь или встраивать в систему (со всеми формальными сроками на доработку) или уметь обоснованно объяснять, почему данная хотела/изменение не приемлемы в контексте данного проекта/задачи.
Тогда у вас не будут пенты и триады расползаться в круг и принимать аморфную форму..
Нет ни одного человека, который учитывает все части триады или пентады. В итоге она всегда в серьезном дисбалансе. И все изменения в компаниях - это бег догоняющих солнце.

У вас проблема в чем. Вы хотите все "сделать сам". Это приемлемо на в небольших фирмах и тп. Но один человек не в состоянии объять необъятное. Такой человек "знает много но не знает самого главного" - толку от него в серьезных проектах - нету, только будет ставить вопросы которые никому по сути не нужны. А нужны грамотные: руководитель проекта (ментор, драйвер, он же архитектор возможно), системный аналитик и БА + программисты. Вот и все. Можно исключить БА, т.к. зачастую Системный аналитик может выполнять его функцию. Но если речь о большом проекте, где задействованы несколько компаний, который интегрируются и разрабатывают едино решение - то выделенный БА удобен, БА компаний могут митапить о "утверждать" все требования от бизнеса для каждой из сторон.
Gluk_1C; David_1C; +2 Ответить 1
127. artempo 19.12.17 11:13 Сейчас в теме
(125) ок, я получил ответ на свой вопрос.
Благодарю.
Жду новых интересных статей.
126. AntonSm 24 19.12.17 10:45 Сейчас в теме
(124) Ты никому ничего не должен. Это нормально.
Но Иван тоже никому ничего не должен. И это тоже нормально.
125. 1c-intelligence 7979 19.12.17 10:41 Сейчас в теме
(124) а, теперь я вам чего-то должен?

Суррогат - это возможность.
124. artempo 19.12.17 10:29 Сейчас в теме
(123) Чтобы разобраться ДОЛЖЕН я всё-таки или нет,
вы должны ответить на вопрос - суррогат это всегда только плохо?
123. 1c-intelligence 7979 19.12.17 09:52 Сейчас в теме
(122) блин, люди, да что с вами такое!
Кто вам так сильно вбил в голову слово ДОЛЖЕН?!
Кто тот гад, который каждый день ходит и говорит, что вы ДОЛЖНЫ?

Ладно вы на работе все, что вам говорят, воспринимаете как приказ - ты ДОЛЖЕН.

Но блин тут-то, читая статьи, как вам это в голову приходит - что вы ДОЛЖНЫ?
Неужели настолько херово текст написан, что не понятно - здесь про ВОЗМОЖНОСТИ!

Возможности дать больше, и получить больше. Возможности стать лучше, чтобы давать и получать больше. Взглянуть на мир шире, увидеть возможности, воспользоваться ими - простыми, понятными, немного проверенными на практике - и получить больше, давая больше. Хотя бы бизнесу.
apd1c; Dem1urg; +2 Ответить 1
122. artempo 19.12.17 09:44 Сейчас в теме
(117) Возможно и так...

Все так делают. Пытаются, доказывают, а потом говорят "да пошли вы все в жопу, буду делать как скажете, сами увидите, что были неправы".

Только у меня постоянно вертится такой вопрос - а ПОЧЕМУ я должен думать за других? Почему должен уберегать их от ошибок?
За меня никто не должен думать и мне помогать, а я должен.
Насколько я понимаю из ваших статей и ответов - что единственно правильный путь - это вот такой путь мессии. Когда я должен и за себя и ещё за кучу людей вокруг - думать, принимать решения, исправлять, направлять.
По вашему ДОЛЖЕН, а сможете ответить на вопрос - ПОЧЕМУ?
121. 1c-intelligence 7979 19.12.17 09:16 Сейчас в теме
(120) кратко не изложить - вы не поверите. Я попробую, конечно, а там сами решайте.
Публикация все равно будет.

Любое изменение бизнеса будет успешным, если будет одновременно учитывать и изменять как минимум три характеристики системы - бизнес-процессы, систему мотивации и автоматизацию. Это триада.
Еще лучше - добавить цель и систему управления. Это пентада.

"Ключевость" в том, что такая комбинация встречается крайне редко.
Типовое внедрение 1С, особенно силами франчайзи - это снапшот бизнес-процессов, системы мотивации, целей и системы управления. Этот снапшот оформляется в виде ТЗ и запускается автоматизация.

Но, в реальности снапшота не происходит - все части триады и пентады продолжают развиваться. При этом продолжается автоматизация снапшота, который уже устарел. Идет автоматизация прошлого.

И параллельно идет разбалансировка всех частей триады. Автоматизация не учитывает всех особенностей бизнес-процессов. Система мотивации заставляет людей делать не то, что нужно, а то, за что начисляется KPI. Бизнес-процессы не ведут к обозначенной цели. Система управления не разруливает конфликты бизнес-процессов, а смотрит внутрь себя.

Возвращаясь к программистам и тому, что каждый должен делать свое дело. Нет ни одного человека, который учитывает все части триады или пентады. В итоге она всегда в серьезном дисбалансе. И все изменения в компаниях - это бег догоняющих солнце.
120. Octopus 337 19.12.17 08:06 Сейчас в теме
(119)
это ключевая ошибка, корень бед бизнес-систем. Но это отдельная тема.

А вкратце, в чем "ключевость"?
119. 1c-intelligence 7979 19.12.17 07:37 Сейчас в теме
(88)
Каждый должен заниматься своим делом, архитектор думать и анализировать, менеджер организовать, БА и СА подливать информацию в общий котел проекта. Программист - программировать. Вот и всё.

это ключевая ошибка, корень бед бизнес-систем. Но это отдельная тема.
118. 1c-intelligence 7979 19.12.17 07:36 Сейчас в теме
(90)
Главное во всем иметь меру)

и помнить о цели. Иначе получится Догвилль.
117. 1c-intelligence 7979 19.12.17 07:35 Сейчас в теме
(98)
Как-то я уже пережил этот период в своей жизни, когда хотел всех научить как "правильно".

подозреваю, что не пережили, а бросили, не стали развивать, потому что не получилось превратить свою уверенность в решения.
Все так делают. Пытаются, доказывают, а потом говорят "да пошли вы все в жопу, буду делать как скажете, сами увидите, что были неправы". А потом - суррогат, увы.
116. 1c-intelligence 7979 19.12.17 07:32 Сейчас в теме
(108) речь не о том, чтобы делать за других их работу. А о том, чтобы разбираться в ней. Понимать принципы, алгоритмы и технологии.
Разница колоссальная.
Например, как между автоматизацией работы отдела программистов и автоматизацией работы хлебобулочного производства.
115. ifilll 18.12.17 16:42 Сейчас в теме
(108) Спасибо Сергей, мне духу на портянку такую не хватило бы.

А по сути намекал как мог автору, что желательно что бы все работали, тогда может и не нужного лишнего знать, да побольше с семьей общаться, да разными "хобями" полезными заниматься (без разнообразия деятельности мозг то помирает быстрей, руками что поделать всегда нужно).
Gluk_1C; serg_gres; +2 Ответить
114. vvh74 18.12.17 12:46 Сейчас в теме
(107)
У вас постоянно взаимоисключающие параграфы.
Вот:
А пекарю должны были что то объяснять?
и вот:
А в случае, если на него валят не его отаетственность, - защищать свою честь, достоинство и собственную ценность

В одном месте ему не должны ничего объяснять, в другом он должен разбираться, где его ответственность, а где нет.
Так делать, что говорят или все-таки разбираться и отстаивать?
Либо у вас что-то очень плохо с логикой, либо вы, Сергей, просто из тех самых людей, которые умело обращаются с понятием "ответственность".
Оставьте свое сообщение