Сергей встрепенулся, оторвался от компьютера и снял наушники. Сбоку стояла Лена, менеджер по снабжению, с какими-то бумагами в руках и вопросительно на него смотрела.
— Чего? – спросил Сергей.
— Интервью.
— Чего?
— Мы с вами договаривались об интервью для корпоративного журнала.
— Блин, точно… Прямо сейчас? Я тут поработать хотел, специально вышел в каникулы…
— Прямо сейчас. – твердо сказала Лена. – Я, как вы заметили, тоже специально вышла в каникулы, и только ради интервью.
— А, да, точно… — Сергей начал волноваться. – Ладно, давайте. Надолго это?
— Не знаю. – пожала плечами Лена. – Вопросов много, быстрее начнем – быстрее закончим.
Лена решительно взяла свободный стул, уселась рядом, разложила свои бумажки, взяла ручку и приготовилась что-то записывать. Потом подумала несколько секунд, достала из кармана смартфон.
— Не возражаете, если на диктофон запишу? Неохота писать, потом стенографию сделаю.
— Ладно. – пожал плечами Сергей. – Один вопрос у меня, для начала – нафига?
— Что нафига?
— Интервью нафига.
— Люди хотят знать больше о своих руководителях.
— Нафига?
— Ну блин, Сергей…
— Чего? Я серьезно. Я ведь тоже отношусь к людям, так?
— Так.
— Но мне совсем не интересно знать о руководителях. Как они работают, что умеют – да, но это не через интервью познается, а на практике. Какое мне дело до их личной жизни, например?
— Вы журналы читаете?
— Нет.
— Ну понятно… А в инстаграме на кого подписаны?
— Ни на кого, я там не регистрировался.
— Потому что «нафига»?
— Да.
— Ладно, тогда не пытайтесь понять. А еще не портите мне интервью своими сентенциями. Мы с вами договорились, давайте следовать плану.
— Хорошо. – вздохнул Сергей.
— У меня два типа вопросов. Нет, три… Первый – заранее заготовленные, стандартные, можно сказать. Второй – вопросы от людей, написанные анонимно. Третий – вопросы, возникающие по ходу. Понятно?
— Понятно. Еще один вопрос.
— Какой?
— Почему мы этим занимаетесь? Вы же менеджер по снабжению.
— А какое это имеет значение?
— Ну у нас же есть Татьяна, харэ-директор, вроде это больше на ее обязанности смахивает…
— Не знаю, кто куда и что смахивает, но корпоративный журнал не отдел персонала пишет. Это, можно сказать, народное творчество под эгидой директора.
— Ясно. Дайте угадаю: вы – орг?
— Кто? Орк?
— Нет, орг. Ну там культорг, спорторг, агитбригада… В институте занимались подобной деятельностью?
— Вообще да, но какое это имеет значение?
— Да я так, для себя… Давайте начинать.
— Хорошо. Первый вопрос – расскажите о своей семье.
— Жена, двое детей.
Лена сидела и смотрела на Сергея, ожидая продолжения. Через несколько секунд поняла, что его не будет, и немного скисла.
— Это все?
— Все, что нашим уважаемым людям стоит знать о моей семье. – серьезно ответил Сергей.
— Чем жена занимается? Дети? Учатся? Или в садик еще ходят?
— Это не имеет ровным счетом никакого значения.
— Ясно, как хотите. – расстроенно вздохнула Лена. – Вопрос номер два – где вы учились?
— В институте.
— Ну понятно, что не в консерватории. Давайте поподробнее, Сергей.
— Так вам моя анкета нужна, что ли? Вся эта информация есть в отделе кадров, даже скан диплома.
— Мне интересно, что вы об этом скажете.
— А, вон что… Политехнический институт, приборостроительный факультет, квалификация инженер, специальность – измерительная техника.
— Это какой-то отдельный вид техники?
— Ну да… И методики. Оттуда любовь к цифрам и статистике.
— Как учились? Хорошо? Диплом красный?
— Да, диплом красный. Учился плохо, но вовремя понял, как там все устроено.
— И как?
— Надо быть в середине.
— Как это?
— Ну не отставать от толпы, идти в общем потоке. Вовремя сдавать лабы, коллоквиумы, контрольные, курсовые и так далее. Если все пишут бомбы, то участвовать. Если все пишут шпоры, то тоже участвовать. Ты помогаешь, тебе помогают. Если отстанешь – например, не сдашь вовремя зачет, то останешься один и будешь мучиться с преподом один на один – искать его, вылавливать, бегать, копошиться. Толпой легче.
— То есть в институте вы были прямой противоположностью себя нынешнего?
— В смысле? Нет… Почему?
— Ну сейчас вы явно не держитесь толпы…
— Так сейчас я в другой системе, и цели другие.
— А в чем разница?
— В институте главное – пройти этот путь с минимальными потерями, и по ходу чему-то научиться. Там нет смысла, например, менять систему, даже пытаться не стоит. Она годами, если не веками, выстраивалась так, как ей одной выгодно. У нее, у системы, есть определенные требования – надо лишь их выполнять, чтобы нормально проскочить и жить дальше. Как бюрократия.
— Бюрократия?
— Ну да. Она же везде есть? Можно просто сидеть и ныть – вот, бюрократию развели, жизни не дают. А можно присмотреться, понять принципы функционирования системы, и принять решение – следовать этим законам, или нет. Главное – понимать, чего ты хочешь добиться.
— И чего вы хотели добиться в институте?
— Закончить его.
— А на работе чего хотите?
— Поменять систему.
— Она вас не устраивает?
— Это странный вопрос, Лена… Как меня может не устраивать система, созданная не мной? Это – система Евгения Викторовича, он ее создал так, как считал нужным. Ну или как получилось, не суть важно. Любая система имеет право на жизнь, ну и на смерть – если мешает другой системе. А человек просто выбирает для себя – остаться и принять, остаться и менять, уйти. Все. Никаких оценок – плохая там, или хорошая, только факты и цифры.
— Тогда почему вы хотите, или точнее – решили менять эту систему?
— Потому что я программист.
— Где-то я это уже слышала. – улыбнулась Лена. – Это уже мем какой-то.
— Суть работы программиста – изменение систем. Ну, если он не сидит на сопровождении или тех.поддержке – в этом случае его задачей будет поддержание системы в рабочем состоянии. А нормальный, или стандартный программист строит и меняет системы. Такая работа.
— Погодите… Программист ведь меняет системы, которые связаны с автоматизацией, верно? Ну или с информационными технологиями. Сайты там, мобильные приложения, системы учета. Разве нет?
— И да, и нет. Принципиальной разницы нет, просто информационная система более пластична, проста и доступна для изменений. Берешь и меняешь, и она тут же отзывается – не надо никого уговаривать, ничего доказывать, искать компромиссы, спорить и ругаться. Вот напишете вы код: X=2. Что произойдет?
— Не знаю, я не программист…
— Блин, ну это что-то типа математики же…
— Переменной X будет присвоено значение 2?
— Да. А теперь представьте, что X – это не переменная, а человек. Менеджер по снабжению Лена, например. И вы говорите – так, теперь ты смотришь на входящие заявки не сто раз в день, а один раз, с утра, принимаешь их в работу и больше не отвлекаешься. Что будет дальше?
— Ну, раз речь обо мне, то я… А почему раз в день?
— Вот и ответ. – улыбнулся Сергей.
— Какой ответ? Я же вопрос задала.
— Ваш вопрос и есть ответ. У переменной вопросов нет, она подчиняется беспрекословно. Это абсолютно пластичный элемент системы. А вы, Лена, не пластичный, а довольно упругий элемент. Если на вас чутка надавить, то вы сопротивляетесь, спорите, вопросы задаете, ругаетесь, бежите звать маму, и, в конце концов, возвращаетесь в исходное состояние. И система, соответственно, тоже. Изменений не происходит.
— То есть главная проблема – люди?
— Не проблема, а задача, или особенность. Это несколько утрированный пример, конечно… Не только люди сопротивляются изменениям. Возьмите, я не знаю… Кусок дерева и нож, и попробуйте выточить фигурку, любую. Тоже ведь не сразу получится?
— У меня так вообще ничего не получится. – улыбнулась Лена. – Еще и без пальцев останусь.
— Не в этом дело, а в скорости и методах внесения изменений. Переменная меняется за долю секунды, дерево – за часы, человек – как повезет, могут годы уйти. Аналогично и методы воздействия, или внесения изменений. Переменной достаточно знак равенства поставить, чтобы все получилось. Деревяшке хоть сто знаков равенства поставь, ничего не выйдет – надо брать нож, или станок, и фигачить. Воздействие на человека – еще сложнее. Кому-то достаточно приказ отдать, кого-то – попросить, некоторые на мотивацию ведутся, еще помогают инструкции, угроза увольнения, автоматизация и т.д. Просто другой арсенал методов, но суть одна: изменение.
— Так, я забыла… А причем тут программисты?
— Суть работы программиста – изменения. Никакая другая профессия из известных мне не стоит так же близко к изменениям, как программист.
— Почему же тогда все программисты не кинулись организационными изменениями заниматься?
— Все – не знаю. Но занимаются многие. Этот рынок пока пуст, но потребность – колоссальная. У всех, до единой, организаций одна и та же проблема – корявые изменения. В большинстве случаев их просто нет, потому что никто ими не занимается. В мелком бизнесе еще как-то справляется собственник, а в среднем и крупном, если реально смотреть, почти никто. По одной простой причине – нет такой должности.
— Какой? Программист по изменениям?
— Не важно, программист или нет, дело не в названии. Просто придите в любую организацию, и найдите человека, который управляет изменениями всей компании. Не в том смысле, что подписал некую бумажку «План изменений» и проводит раз в месяц совещания, где контролирует исполнение поручений. А в том, что изучил систему, знает ее недостатки, где что теряется, где идут тормоза, проседает горизонтальная коммуникация, слишком поздно реагируют, и так далее. Такого человека нет.
— Почему?
— А я уже сказал – нет такой должности.
— А руководители?
— А руководители, я прошу прощения, слишком зажрались. Формально – да, изменения – их основная работа. Им дают в руки систему – например, отдел снабжения. Начальник снабжения должен решать две задачи – сопровождение и изменение. Без сопровождения система рухнет, это понятно.
— Ну да.
— Но правильный руководитель должен понимать, что сопровождение – это плохо. Это понимает любой нормальный программист, и организует работу своей системы так, чтобы она требовала минимум его внимания. А руководитель – наоборот. Он делает все, чтобы система не могла без него существовать. Все вопросы, даже минимально значимые, завязывает на себя – согласования, принятие решений, вплоть до подготовки отчетов. Вот представьте, есть такая система – электронная почта. Сейчас вы пишете письмо, и оно само отправляется адресату, когда вы кнопку нажали. Так?
— Вроде так.
— Большинство приличных компаний арендуют почту, потому что так проще и быстрее – платишь небольшую сумму, и у тебя все работает, ты вообще не занимаешься сопровождением. А есть неприличные компании, или точнее – неприличные системные администраторы и ИТ-директоры, которые всех вокруг убеждают, что нельзя доверять сервисам, надо держать сервер электронной почты у себя. И что в итоге? Электронная почта, эта простейшая, по сути, система, начинает пожирать ресурсы и требовать сопровождения. Под нее стоит сервер, который и сам денег стоит, и на затраты ложится, и администрирования требует, и даже руководителя. Руководитель электронной почты. Если дойти до маразма, то этот руководитель будет согласовывать каждое пересылаемое письмо.
— Ну, это и правда маразм…
— Пример утрированный, но суть ведь ясна? Вот ваш начальник снабжения, например. Сколько раз в день вы к нему бегаете, чтобы подписать спецификацию?
— Несколько. У нас процесс такой – надо согласовывать каждую спецификацию.
— А кто этот процесс написал?
— Я не знаю…
— А я знаю. – Сергей отвернулся от Лены, порылся в бумагах на столе, достал документ листов из двадцати, скрепленный и увешанный подписями и печатями. – Вот, процесс снабжения. Смотрим на штамп, кем разработано?
— Наш Василий…
— Ваш Василий. – кивнул Сергей. – Он – автор системы, он же – владелец процесса, если в терминах чернокнижников.
— Кого?
— Ну этих, которые процессами всеми ведают. Вася, по сути – программист, который создал систему. С алгоритмами, ролями, входами и выходами, контрольными процедурами и записями. И он же решил, что надо согласовывать каждую спецификацию, даже если мы заказываем одно и то же количество одной и той же номенклатуры, у одного и того же поставщика в течение десяти лет. Вот нафига, скажите мне?
— Не знаю. – пожала плечами Лена. – Вообще, Вася постоянно жалуется на то, что ему надо согласовывать спецификации.
— Сам придумал, сам жалуется. – улыбнулся Сергей. – Плохой программист, я же говорю. Или чересчур хитрожопый. Ведь он, по сути, сделал так, чтобы система без него не работала. Потому что он, сознательно или подсознательно, считает, будто его выгонят, если он сам не наделит себя какой-то важной функцией. Вроде того же согласования. А потом жалуется, что зашивается, времени нет, некогда присесть и подумать о развитии. Понимаете, на что у него времени нет?
— На изменения?
— Именно! – воскликнул Сергей. – Самый настоящий плохой программист, таких очень много на заводах. Сидят где-нибудь возле бухгалтерии, и делают вид, что очень заняты, решая, по сути, задачи, которые должна решать система, ими же и создаваемая. Все бегают, у всех жопа в мыле, а на развитие времени нет. Потому что все время занято системой. Руководитель сам себя поместил в систему, притянул к себе кучу нитей, связей, как в матрицу засел, не в силах пошевелиться.
— А как надо?
— А надо в стороне стоять, как настоящий программист. Создал первый вариант системы, запустил, отошел в сторону, и наблюдаешь. Сначала – да, бегаешь, пожарные вопросы закрываешь, срочные изменения вносишь, даже за пользователей работаешь, если того требует ситуация. Но пожар-то надо тушить, а не раздувать. Потушил, стабилизировал систему – все, отойди в сторону! Наблюдай, отлаживай, замеры делай, ищи потери, прорехи, и меняй! Делай лучше, оптимизируй, ускоряй, и так далее. Внес изменения – снова стабилизируй, наблюдай, измеряй, анализируй, оценивай.
— А что за стабилизация? Это метод какой-то?
— Ну да, из арсенала управления качеством. Про цикл Деминга слышали?
— Да, конечно.
— В литературе по управлению качеством я встречал немного другую его версию, она мне больше нравится. Придумай изменение, внедри в систему, стабилизируй, оцени результат. После внедрения любого изменения систему начинает лихорадить, показатели скачут, вылезают проблемы – те самые пожары. Стабилизируешь, чтобы вернуть систему в управляемое состояние, и только потом оцениваешь эффект от своих изменений.
— Так, стоп. – нахмурилась Лена. – Что-то наше интервью в лекцию превращается…
— Так вы же владелец процесса. – улыбнулся Сергей. – Модерируйте. Вы этот процесс организовали, вам известна его цель, не становитесь его заложником. Останавливайте меня, направляйте в нужное русло.
— Хорошо. Подытожим: руководитель должен вносить изменения, а не заниматься одним сопровождением. Так?
— Да.
— И вы будете в этом направлении работать, так?
— В смысле?
— Ну, делать из руководителей – программистов.
— Нет, зачем… Что вы к этому слову прицепились?
— Так вы сами прицепились. – улыбнулась Лена. – Везде вставляете его – программист, программист, программист…
— Я не пытаюсь прославить программистов, просто аналогию провожу, как умею. Если найдете более подходящее название для человека, который стоит в стороне от системы и меняет ее, то буду пользоваться вашим определением.
Лена задумалась. Сначала пристально глядела на Сергея, потом отвела взгляд куда-то в сторону.
— Блин, не знаю даже… Руководитель не подходит?
— Нет. Ну то есть может и подходит, но вам каждый раз придется продираться через тернии стереотипов, главный из которых: руководитель – это босс, шишка, начальник, самый главный. Так же и я мучаюсь, объясняя сходство между программистом и руководителем.
— Ну да, это видно… — улыбнулась Лена. – Может, бизнес-аналитик?
— Возможно, но мне не нравится. Слово «аналитик» смущает, отдает некой пассивностью, что ли… Вроде как сидит такой чувак, смотрит на бизнес-процессы, и анализирует, анализирует, анализирует… А потом выдает некое заключение. Понимаете? Выдает! Бумажку там, или презентацию – отдает тем же руководителям, и сваливает. Все читают о своих проблемах, а чего делать – не знают. Даже если аналитик напишет раздел с рекомендациями, толку мало – все и так знают, что надо делать, ну примерно хотя бы. Но делать-то никто ведь ничего не будет, так?
— Не знаю… Ладно, я поняла. Не знаю я более подходящего слова. Так и будете программистами называть?
— Нет, я выдумал другое определение – бизнес-программист.
— Выдумали?
— Ну да.
— А зачем?
— Чего зачем?
— Зачем вы выдумываете термины и определения?
— Не зачем, а когда.
— Когда?
— Да, когда. Когда не могу найти подходящего.
— Так если задаться такой целью, то можно, наверное, найти…
— И сколько это времени займет?
— Не знаю…
— Вот и я не знаю. Я себе какой-нибудь лимит ставлю, по времени – например, один час. Сижу в интернете, ищу. Если нашел – беру подходящее определение. Если не нашел – придумываю сам.
— Так это же… Не научно.
— А мы тут не наукой занимаемся. – улыбнулся Сергей. – А практикой. Я ж не диссертацию пишу, и не статью в научный журнал, где есть определенные требования и стандарты. Моя задача – результат, и некая правильная терминология на него ну никак не влияет, согласитесь.
— Так, сходу, не могу согласиться… Я бы поспорила, наверное.
— Да ради Бога! – еще шире улыбнулся Сергей. – Только без меня, ок? Я этой хрени наелся еще в аспирантуре, когда на каждый чих надо искать источники, указывать номер страницы и год издательства, просто ради того, чтобы соблюсти некие выдуманные кем-то правила.
— Погодите, а как вас будут понимать люди-то?
— Какие люди? – недоуменно поднял брови Сергей.
— Ну, я не знаю… Вот изложите вы какой-то метод, или термин, на бумаге, его кто-то прочитает и скажет, что вы придумали то, что уже кто-то давно придумал.
— Ну, и что?
— Начнет с вами спорить, и окажется, что вы не правы.
— В чем не прав?
— В том, назвали существующий метод своим каким-то словом.
— И?
— Что и?
— Ну мне-то что с того?
— Как что с того? Это же неправильно!
— Блин, Лена… Вы как редакционная коллегия. Правильно или неправильно – весьма относительные категории. Если вы пишете диссертацию, то попадаете в некую систему, с определенными правилами. Там нельзя давать методам свои названия. Почему, как, зачем – не важно, такова система. Если хотите быть в этой системе, то нужно следовать этим правилам. Это как система координат, понимаете?
— Не совсем…
— Цели, ценности, оценка результатов. Для диссертации, или научной статьи важны отсылки. Грубо говоря, есть некий показатель – размер списка использованной литературы. Вы ведь писали диплом?
— Да, конечно…
— У вас был большой список литературы?
— Ну, я не помню…
— А я помню, он листа три занимал. Почему?
— Не знаю, наверное вам действительно надо было все это прочитать, чтобы работу сделать…
— Ну-ну… Просто требования такие – список должен быть большим. Смысла в этом требовании – ровно ноль, но оно есть, и никто в здравом уме его не будет оспаривать. А диплом написать надо. Поэтому просто применяется рекурсия.
— Чего?
— Берете одну книжку, нужную вам. В ней есть список литературы. Указываете эту книжку, и с десяток источников, перечисленных в ней самой. Если не хватает, берете в библиотеке пару книг из этого списка, открываете в конце – там опять список литературы, и тащите еще пару десятков названий. И так, пока не надоест.
— А смысл?
— Никакого. Только требования выполнить. Потому что в той системе координат это важно. А в нашей?
— В какой нашей?
— Ну вот у нас компания, и мы занимаемся изменениями. Мне, допустим, надо некий план составить – что, где и как мы будем менять. Нужен список литературы?
— Не знаю…
— А я знаю – нахрен он там не сдался. Нет такого требования. Он даже вреден.
— Почему?
— Потому что полно людей, которым заняться нечем. Напишешь, что используешь методы из ТОС – обязательно найдутся люди, которые прочитают книжку и начнут сыпать умными вопросами, типа а почему тут вот так, если в книжке – вот так? И вместо изменений мы займемся защитой очередной диссертации.
— А что важно в нашей системе координат?
— Результат. Методология – потом, и очень малому кругу людей.
— Почему?
— Сам не знаю. – пожал плечами Сергей. – Я же делал уже несколько проектов изменений, и результаты были неплохими – так, по крайней мере, Курчатов сказал. Я, как дурак, потом сел и написал все методы, которые применил – с названиями, отсылками, номерами страниц и цитатами. Кто его читал?
— Кто?
— Никто.
— Почему?
— Вы уже спрашивали. – улыбнулся Сергей. – В душе не знаю, почему. Насрать всем, как именно был достигнут результат. Ну, то есть, не всем – мне-то интересно, поэтому я и пишу. Ну и тем, кто со мной работает, интересно.
— Это кто, например?
— Стас, программист.
— Стас тоже занимается изменениями?
— Раньше занимался. Это он внедрял скрам в отделе конструкторов пару лет назад. Сейчас я его тоже в команду включил, так что ему придется прочитать дневник проекта.
— И запомнить выдуманные вами названия методов?
— Ну да, иначе мы просто разговаривать не сможем. Как вы это себе представляете? Попробуй применить метод, ну этот, как его, мы его применяли в снабжении, да нет, не этот, а вон тот, блин, ну ты тупой, не первый, а восьмой. Проще потратить пару минут, дать название и использовать его.
— Ладно, я поняла… Главное – результат?
— Для компании – да. Она – как пациент в больнице. Главное – чтобы вылечили, а как там называются болезни, таблетки, методы лечения – вообще без разницы. Потом, когда все получится, может спросит, а может – нет, просто притащит коньяк, пожмет руку и убежит по своим делам. А врач поделится своим опытом с коллегами, если захочет.
— А если решит стать КМН, то придется все-таки в библиотеке посидеть…
— Ну да… Но практика интереснее.
— И коньяк. Понятно. – кивнула Лена и выключила диктофон.
— Все? – спросил Сергей.
— Нет. – загадочно улыбнулась Лена. – Сейчас – анонимные вопросы от коллег.
— Блин… — Сергей картинно уронил голову, как будто шея вмиг стала пластичной.
— Не, там самое интересное.
— Кто бы сомневался…
Комментарии (89)
acyp
04.01.2019 10:22Если нужна терминология для участников процесса создания и сопровождения систем, то зачем изобретать велосипед? Есть отрасль, существующая больше 4х тысяч лет и которая все это время и занимается созданием и сопровождением систем… строительство. Конечно не созданием, а строительством, не сопровождением, а обслуживанием (очень давно, уже в другом государстве система ЖКУ была подчинена МинСтрою). Ну и брать оттуда роли да термины, ну может немного их «отполировать»…
Hardcoin
04.01.2019 10:23+2Читаю с интересом, а вот про диссертацию не мог пройти мимо.
когда на каждый чих надо искать источники, указывать номер страницы и год издательства, просто ради того, чтобы соблюсти некие выдуманные кем-то правила.
Ссылки на источники должны быть раскиданы по тексту. Есть тезис — есть номер источника. Если в конце просто список источников, случайно собранный — это, конечно, мусор.
Зачем вообще нужны ссылки на источники? Что бы читатель мог узнать, существует ли то, что написано или оно выдумано. Если написано без ссылки, например, что "люди переоценивают малые вероятности (считают, что они больше, чем на самом деле)" — нужно или верить на слово или проводить свое исследование. Но наука так не может работать — нельзя верить всем на слово, потому что шарлатанам "попрёт карта".
Поэтому все и должны либо ссылаться на результат эксперимента (с описанием методологии), либо на чужое исследование (надёжность которого можно проверить).
nmivan Автор
04.01.2019 11:08Что бы читатель мог узнать, существует ли то, что написано или оно выдумано
все верно, только у героя этого текста нет читателей. Поэтому стараться не для кого.
А вот результат есть кому почитать.Hardcoin
04.01.2019 11:41Я к тому, что у правила есть смысл и цель. И рандомно набранные источники в списке литературы возникают потому, что некоторые преподы не знают, в чем этот смысл состоит или им плевать.
Соблюдать же это правило, когда читателей нет — действительно нет смысла. Вполне достаточно проверить для себя.
janvarev
04.01.2019 11:16> Что бы читатель мог узнать, существует ли то, что написано или оно выдумано.
Проблема в том, что в подавляющем среднем эти ссылки и факты никто не проверяет. Никому не интересно (проверено грустной практикой написания научных работ и дисера).
А шарлатанам, увы, карта и так прет. По моим наблюдениям, основным фильтром в науке остается не соблюдение формальных правил, а добросовестность научных руководителей. Т.е. проверка идет не фактов, а принадлежности к той или иной научной структуре и подтверждений компетентности от старших товарищей.
> Я, как дурак, потом сел и написал все методы, которые применил – с названиями, отсылками, номерами страниц и цитатами. Кто его читал?
— Кто?
— Никто.Hardcoin
04.01.2019 11:36Честно, не знаю, как работает наука в России и работает ли вообще. Лично я ссылки проверяю.
В декабре прочитал две книги — биохакинг мозга, Дэйва Эспри и "думай медленно, решай быстро", Даниэля Канемана. У обоих есть источники. Но Эспри подтверждает свои утверждения ссылками на глянцевые журналы, Канеман — на слепые рандомизированные исследования. После третьей случайной ссылки у Канемана я перестал проверять — всему, что он написал, можно верить, фактически, на слово. Не потому, что он умный или принадлежит к какой-то научной школе, а потому, что он сам всем подряд на слово не верит. Конечно, часть исследований сделана по стандартам семидесятых (слишком маленькие группы, например), но взятых совсем с потолка утверждений у него нет.
подтверждений компетентности от старших товарищей
Это подтверждение того, как человек работает с источниками. Если он хоть иногда берет данные с Пикабу, то копаться в его работах — трата времени (та самая ложка говна в бочке меда). Но для этого нужно знать, откуда он берет данные, верно? А что бы убедиться, что он не набрал источников случайно, они и должны быть привязаны к местам в тексте. Так можно проверить за вменяемое время.
проверено грустной практикой написания научных работ и дисера
Если ваша научная работа собирается изменить индустрию или по масштабам тянет на Нобелевскую — всё будет проверено. Не каждым читателем, но каждым сотым. Если же работа в целом проходная (такие тоже иногда нужны, я не имею ввиду что-то обидное) и читателей у неё вряд ли будет больше двух — то неудивительно. Весь вопрос, какое научное значение для других вы сами вкладываете в свою работу. Если оно небольшое, то источниками/методологией экспериментов можно пренебречь.
janvarev
04.01.2019 11:58> Лично я ссылки проверяю.
Вы существуете! :)
Серьезно, я очень рад, что кто-то обращает на такие вещи внимание. Увы, проверка занимает много времени, и почти никто этим не занимается.
В принципе, согласен — наличие источников позволяет убедиться, что человек берет данные не с потолка. Как вы правильно указываете, смысл в этом правиле действительно есть.
Увы, как я уже говорил, это скорее формальный фильтр, который работает плохо. В большую часть работ (хорошо, мы сейчас говорим про области типа программирования и психологии) можно добавить ссылки путем копирования библиографии какой-нибудь статьи по схожей теме. Ну, или банально просмотреть указанные источники и добавить то, что более-менее релевантно. Т.е. для недобросовестного исследователя это работу усложнит не сильно, а вот добросовестному — сильно.
И еще. Часто основополагающие работы («меняющие индустрию») ссылаются не на такое большое число источников, и обладают не столь внушительной статистикой. В пример можно привести работу Маслоу «Мотивация и личность». Он сам говорит, что выборка по статистическим меркам у него смешная (в районе 10 реальных людей и 10 исторических личностей, точно сейчас не скажу); и, например, он сам признает что в этом смысле проигрывает в сравнении с бихевиористами, которые занимали главенствующие позиции в психологии в США в это время.
Другой пример важной научной работы, которую «никто не удосужился проверить» — реакция Белоусова — Жаботинского (историю можно глянуть в Википедии, важнейший факт просто никто не удосужился проверить).
В общем, не все так просто с источниками, статистикой и научной работой.
Peacemaker
04.01.2019 12:54В большую часть работ(...) можно добавить ссылки путем копирования библиографии какой-нибудь статьи по схожей теме.
Странно, в требованиях к магистерской диссертации, которую защитил летом, было одно из основных требований к списку литературы — на каждый элемент списка должна присутствовать ссылка в тексте. Просто так «скопипастить» это требование не позволяло.
rinaty
04.01.2019 16:23Я лично, если что интересное пишут со ссылкой на источник, обязательно найду и почитаю сам источник. Редко но бывает, что в источнике все уже не так интересно как было в его вольном пересказе :)))
А про ссылки на литературу конечно есть проблема что они обязательно должны быть в количестве Х+ (где Х зависит от вида работы: диплом, статья или кандидатская), но обычно это не сложно: берется работа по теме (желательно зарубежная там с источниками получше) и переписывается из нее введение в котором делают анализ того что было сделано по этой теме вместе с источниками (понятное дело что оставляешь только нужное). А вообще по хорошему если занимаешься темой то и так знаешь все ссылки и схожие работы.
Hardcoin
04.01.2019 17:04важнейший факт просто никто не удосужился проверить
Перепроверять эксперименты в десятки раз сложнее, чем их описания. Я проверяю только формальное описание, размер группы, методологию. Сам эксперимент конечно не провожу повторно, это неподъемная сложность для меня.
И эта проблема совсем другого рода. Откинуть факт, потому что лень проверять — это не то же самое, что принять что-то за факт, потому что лень проверять.
barbanel
04.01.2019 11:31+2Оффтоп
da-nie
04.01.2019 18:25+2Что бы читатель мог узнать, существует ли то, что написано или оно выдумано.
:)
iig
04.01.2019 11:04Я где-то слышал, что придумали целую лженауку по управлению, кибернетику кажется. Похоже, что ее вот-вот переизобретут.
nmivan Автор
04.01.2019 11:08кажется, героя этого текста наука не особо интересует. Равно как и ее научность, или лженаучность.
andyudol
04.01.2019 14:36+2Что-то я не слышал, чтобы кибернетика помогла кому-нибудь управлять хотя бы лыжами.
napa3um
04.01.2019 15:04-2Нейросетки всех сортов и прочие альфы-го — как раз отпрыски той самой кибернетики. Прежде всего.
Hardcoin
04.01.2019 17:09Лыжи — это не хотя бы. Это система, для управления которой человек хорошо заточен (потому что заточен управлять своим телом). Вот управлять самолётом — другое дело. Человек на это не заточен, поэтому роботы уже справляются не хуже. Лыжи тоже освоят, но значительно позже. К тому же не видно коммерческой пользы, это тоже снижает приоритет.
andyudol
04.01.2019 17:36+1Только вот сначала человек научился управлять самолётом вручную, а потом уже создал кибернетику. И между этими двумя рубежами были ещё две мировые войны и революция, которые полностью изменили мир.
napa3um
04.01.2019 15:02+2Кибернетику уже раза четыре переизобретали на моей памяти, коммунизм — шесть.
ganqqwerty
04.01.2019 17:40про шесть коммунизмов интересно, кто и когда? Вроде ж основополагающий принцип «штуками для производства всего-всего (заводами, шахтами, нефтяными вышками, электростанциями, землей, железными и асфальтовыми дорогами и прочим в этом духе) владеет все общество, а не какие-то частные руки» никем не переизобретался.
halted
04.01.2019 11:20+1Видимо сейчас удобно пополнить список анонимных вопросов для следующей части )))
Анонимный вопрос — принесет ли пользу практика, чтобы руководители иногда работали наравне со своими сотрудниками, чтобы не терять связи с реальностью?napa3um
04.01.2019 13:09Зависит от рода деятельности и от поставленных исследовательских (архитектурных) задач. Машинисту быть колесом тепловоза раз в неделю, очевидно, бесполезно. А сама постановка цели «чтобы не терять связь с реальностью» говорит о приоритетах процессов поддержки существующей системы перед процессами разработки (изменений). По сути вы из разработчиков пытаетесь сделать сотрудников колцентра, и чтобы они сами вместо директора делали работу по обобщению проблем и формирования направления изменений. Эдакий «менеджмент для бедных» или «я у мамы эффективный менеджер». Если бизнес постоянно горит, что всем нужна постоянная «связь с реальностью», то лучше пересмотреть процессы и кадровую сетку, а не пытаться играть в президента банановой республики.
halted
05.01.2019 00:52Давным давно
в очень далекой галактикеевангелистов упрекали в потере связи с реальностью, теперь про евангелистов не слышно. Много лет и столетий, руководство всех мастей упрекают в отсутствии адекватной оценки трудозатрат подчиненных и представлений об «узких» местах.
Да и среди руководителей, мало кто не согласится с утверждением, что если все хорошо, то не факт, что оно так и есть. Как и среди автобиографических книг великих людей можно найти вечный поиск проблем, а без «спускания с небес», это проделать невозможно.napa3um
05.01.2019 04:22Эту тему можно мусолить вечно, если продолжать говорить беспредметными идеалистическими утверждениями. В каждом конкретном случае есть своя цена обучения горе-руководителя, «оторванного от реальности» (и свои причины этой оторванности). Мой поинт в том, что изоляция компетенций и зон ответственности в общем случае (я бы даже сказал в большинстве случаев) может быть не только вредной, но и полезной, в зависимости от масштабов предприятия (чем компания больше, тем это проявляется ярче). И проблемы изоляции должны указывать не на проблемы самого принципа divide et empire, а, возможно, на низкий уровень компетенции того самого архитектора (или кто там его роль на себя берёт), производящего divide. И эту низкую компетенцию как раз и пытаются компенсировать, порою, «самоорганизацией», сваливанием на исполнителей проблем руководства и размазыванием (а по сути — вымыванием) ответственности путём тотального «горизонтального связывания» всех со всеми. «Не понимаю, как должно работать предприятие, но я соберу лучших специалистов, дам им между собой договориться и посмотрю, что получится. Если не повезёт — уволю, ведь не моя вина, что они не сработались.»
Если упрощать, то не нужно сваливать на одну роль сразу два типа ответственности за один локальный процесс — стратегическую и тактическую. Да, трудно формально разделить стратегию и тактику, но опытный руководитель это видит и понимает, как может возникнуть конфликт интересов при смешивании этих двух уровней. Конечно, менеджмент — штука очень фундаментальная и глубокая, и некомпетентность в этой теме проще компенсировать вариантом «поработаю за станком, как мои ребята» (или «пусть ребята займутся погрузкой деталей, которые они вытачивают»), чем получением соответствующего образования.
VolCh
04.01.2019 14:08Как по мне, то крайне редко это однозначную пользу будет приносить, если её брать позиции, где управление и прочее обеспечение работ не требует много времени, типа бригады грузчиков или отделочников. Стереотипный тимлид разработчиков, да не дай бог в кроссфункциональной команде — уже под сомнением по умолчанию, если не делегировать управленческие полномочия другим членам команды.
avf1906
04.01.2019 12:21Если дойти до маразма, то этот руководитель будет согласовывать каждое пересылаемое письмо.
— Ну, это и правда маразм…
— Пример утрированный, но суть ведь ясна?
вы мою предыдущую работу описали, и руководителя со штатом >3000 человек, и это реальность, а не утрированный примерsergix
04.01.2019 12:23чаще для этого ставят докс вижн, нанимают программиста для его обслуживания, а потом ещё вместо того, чтобы сделать, сидят и мусолят, какой должен быть правильный маршрут для создания служебки на это изменения(причем когда оно будет внесено, оно будет не актуально, и пострадает опять же выручка).
avf1906
04.01.2019 12:42или меняют работу :) так как тратить свою жизнь на это — бессмысленно
sergix
04.01.2019 12:47для региона и семьей — опасно Ваше предложение.
avf1906
04.01.2019 13:11+1Для семьи гораздо опаснее оставаться, так как внезапно выпав из данной системы, с навыками заточенными только под нее — найти что-то другое будет гораздо сложнее, дольше и болезненнее. Впрочем, для сварщика, например, это неактуально, но для них и проблем таких нет, это скорее проблемы среднего уровня. А для высшего менеджмента проблема узкой специализации под систему есть всегда.
zolern
04.01.2019 12:27А я называю ето магией. Дано: ситуация А, надо: ситуация Б, что делать? Магию. Я работал когда-то "просто програмистом" и когда понял, что моих программ ну крайне недостаточно взял и всю систему в компании переделал чтоб у всех меньше пожаров было, а у меня больше свободного от пожарогашения времени. А мой тогдашный начальник так и не понял меня, когда я сказал ему, что я у него работаю волшебником в голубом вертолете. "Да не нужны мне никакие волшебники, мне нужны нормальные работники, у которых есть четкое рабочее время и четкий ответ на вопрос "Когда будет готово?". Вот и остались сейчас у него одни четкие работники да что-то дела у него напоследок вообще никак.
napa3um
04.01.2019 12:50Магия (неформализованное прямое управление) как противоположность тотальной бюрократии — тоже беда. А Истинный Путь, как водится, пролегает где-то посерединке, между тотальным программированием (бюрократизацией) и тотальной магической свободой без ролей и зон ответственности. И путь этот приходится каждый раз заново искать, Универсального Ответа не существует. Чувство меры, разумный выбор — то, что приходится (к сожалению романтичных программистов) всё ещё делегировать несовершенным людям.
zolern
04.01.2019 14:24Согласен, успешный програмист как в хорошем РПГ: И воин, И дипломат, И маг. Но я к чему: почему-то только у программеров есть вообще скилы "маг" :)
napa3um
04.01.2019 14:30+1Скилы «маг» могут быть очень незаметными, программисты-инженеры склонны переоценивать полноту своей картины мира :).
68kOhm
04.01.2019 12:58Вопрос «когда будет готово?» перекрывает вопросы управления и автоматизации со всеми их составляющими. Автоматизатору от этого грустно. Впрочем, стоит признать, это же спасает от неправильной автоматизации (т.е., делаемой людьми с таким же примитизированным и решительным подходом).
68kOhm
04.01.2019 13:19Системность — это всегда сложнее, чем можно себе представить.
Публикация потенциально интересная, давно ничего не читал по этой теме, а здесь и суждения знающего специалиста, и изложение способного к литературе. Однако — как мы испортились — ни сохранить, ни кому-то порекомендовать не захочу. Зачем было наполнять нелитературными выражениями…
nothern_wind
04.01.2019 13:36На счёт списков литературы автор погорячился. Это должен быть самый важный раздел в статье или книге если ты инженер, т.к. тебе приходится время от времени изучать новый материал и если возникают сомнения, первым делом лезешь именно в этот список, чтобы посмотреть на что опирался автор при создании материала. практика — интереснее, но подкреплённая теорией — эффективнее и надёжнее. это помогает уменьшить количество магии, танцев с бубнами и прочей изотерики в создаваемой тобой системе.
VolCh
04.01.2019 14:11Зависит от целевой аудитории статьи или книги.
jaddd
04.01.2019 16:13+1Тоже согласен что от целевой аудитории зависит.
Если отрасль сильно регламентирована — например медицинский центр — то без ссылок на нормативные документы не обойдешься. Или если сильно зависит от технологии — тогда тоже надо ссылки давать на мануал или технологические режимы.
А если писать для небольшой студии вебдизайна, то скорее всего на список глянут только из любопытства да желания пошутить на тему.
В целом надо оценить риски того, что будет и с какой вероятностью если не проработаны источники данных, т.е. список литературы. Если риски минимальны — не надо писать, так как зря время теряем. Если риски велики по вероятности или последствиям, или тем более и по тому и по другому — надо обязательно. Времени не так уж много занимает, а очень многие риски будут минимизированы.
andyudol
04.01.2019 14:14…стоит в стороне от системы и меняет ее…
Это называется бог.68kOhm
04.01.2019 16:20Условно можно и так, только, действительно, с маленькой буквы.
По науке, исчерпывающе описать систему понятиями и средствами самой этой системы невозможно; поэтому для категории «сложная система» уместно предполагать участие вышеестественного; в случае же обыкновенного предприятия быть вне/над системой — это всего лишь привлекать еще не использованные знания и средства и иметь делегированные от владельца права.
jaddd
04.01.2019 16:02У нас в компании уже год как есть начальник производства и зам.директора по развитию производства.
На 100% не совпадает с определением Сергея, но общая мысль при таком разделении обязанностей была аналогичная.
В подчинении у начальника производства — линейные мастера и рабочие, а в подчинении зам.директора по развитию производства — конструктора, технологи конструкторского отдела, производственные технологи и частично программисты.
Разница в том что система по статье это система управления, а у нас система производства. Т.е. включает в себя не только управление, но и технологию производства. Однако в целом есть очень много чего похожего.
По итогам года работы в такой системе я сделал следующие выводы:
1. Система имеет право на жизнь, но есть ряд особенностей которые надо учитывать при ее внедрении(см.следующие пункты).
2. Необходимо добиться совместной работы линейного руководителя и руководителя по развитию. Для этого как минимум нужна единая система мотивации — чтобы не было так, что для одного хорошо, то для другого плохо. Например для линейного мотивация только от объема, а для развивающего бонус от выполненного проекта. При выполнении проекта объем может упасть, так как производятся изменения. В итого краткосрочно линейный страдает и между ними происходит конфликт. Если давать бонус за проект, то обоим, если давать процент от оборота, то тоже обоим. И естественно они должны работать как напарники — у нас они в одном кабинете сидят за соседними столами и на производственных планерках оба присутствуют.
3. Очень желательно, чтобы руководитель по развитию имел своих подчиненных и некоторые смежные обязанности, а не просто только обязанность менять(развивать) систему. Во первых далеко не всегда требуется менять систему, иногда у него будет свободное время и это не даст ему простаивать. Во вторых когда у развивающего нет подчиненных у него слегка меняется мировоззрение, он работает во многом как исполнитель и ему сложнее найти общий язык с линейным (как в плане снижения авторитета как руководителя — подчиненных то нет, так и в плане радикализации идей с персоналом — когда у тебя самого нет в подчинении никого — значительно проще давать радикальные советы — мол этого уволь, а нового возьми) и в любом случае у развивающего должен быть опыт более менее успешного руководства более чем 3 людьми (то есть опыт найма, обучения, решения конфликтов и т.п.).
Не говоря уже о том, что редкий генеральный пропустит идею взять человека только на то чтобы менять систему))) По мировоззрению генерального развивающий это человек с высокой зарплатой и его простой или недозагрузка это серьезные издержки. Поэтому загрузить руководительской текучкой на 25-50% это нормально и правильно.
4. На должность развивающего нужно ставить человека любящего изменения. Того, у которого есть внутренняя мотивация на изменения, если такой мотивации нет — человек не подходит для должности. Он может быть технически супер квалифицирован, иметь свежий взгляд, но если он не хочет искать что можно улучшить — работа не будет сделана. Пока этот человек сам не захочет. Это как с художником — он должен хотеть рисовать, если он умеет рисовать, но не хочет(творческий кризис в эту же тему) — это не профессионал художник, а любитель с непредсказуемым результатом.
5. Важна позиция руководства над линейным и развивающим. Раз в неделю, месяц и/или квартал — делать совместное совещание по модернизации системы. Кто за что отвечает, кто что делал, какие есть мысли по итогу работ за этот период, какие предложения по работе на следующий период. Пускать изменение системы на самотек(то ест на откуп линейному и развивающему) генеральному нельзя. Иначе очень сильно теряется эффективность — линейному очень сложно расставить приоритеты — что важнее выполнить текущую работу или выполнять мероприятия по изменению систему, а развивающему сложно потому что линейный ему не подотчетен и отвечать за выполнение работ он должен только перед вышестоящим.
6. По подчиненности — линейный и развивающий оптимально должны быть на одной ступени иерархии.
Развивающий не может подчиняться линейному — яйца курицу не учат(исключительный случай — линейный хочет сам научится и сам берет к себе такого человека — но это огромнейшая редкость — иногда так поступает генеральный-собственник, когда понимает что ему не хватает знаний).
Линейный может подчиняться развивающему, только если развивающий является генеральным или обособленным руководителем филиала, дивизиона или продукта с персональной ответственностью за результат.
Если интересно, то могу написать статью, где более подробно описать подобную систему и опыт ее внедрения. Только не знаю необходимо ли это на хабре. Все таки это систему управления c IT связано лишь косвенно. Коллеги дайте, пожалуйста, ответ в комментариях — писать статью или нет? Спасибо.rinaty
04.01.2019 17:42по второму пункту, имхо, операционному нужно оставить объем (вообще не только объем а скорее ebitda) просто план этого объема должен быть с учетом всех развивающих инициати.
abar
04.01.2019 17:23+1Я, конечно, понимаю, что выскажу непопулярную точку зрения, но диалоги вида
—Вот напишете вы код: X=2. Что произойдет?
— Не знаю, я не программист…
— Блин, ну это что-то типа математики же…
— Переменной X будет присвоено значение 2?
читаются как
— Вот я вас спрошу — какова орбитальная скорость луны?
— Не знаю, я не астроном…
— Блин, ну это что-то типа типа физики же…
— 1023 км/c при среднем расстоянии между центрами Земли и Луны в 385000 км и средним эксцентриситетом в 0,0549006?
в смысле, что даже когда я курсы по программированию вел, мне ученики отвечали на такие вопросы что-то вроде «икс будет равен двум», а тут Лена, менеджер по снабжению, и вдруг такую формулировку выдает.
Видно, что у автора есть интересные мысли но в формате статей «к главному герою приходят что-то спросить, а потом в немом восхищении внимают его Программисткой Мудрости по несколько часов кряду и пусть весь мир подождет» это вызывает только раздражение. Пишите уже просто мысли сборниками подряд, подписывайте «Иван — Гуру Бизнес Программирования» и будет вам счастье и экономия времени.ganqqwerty
04.01.2019 17:43Да, мне тоже зацепило, надо поправить. Концепция переменной не так уж сильно проста для понимания, у меня ученики понимают только если через коробочки обьяснять.
А формат отличный, почти как платоновские диалоги.
iig
04.01.2019 19:55Вот напишете вы код: X=2. Что произойдет?
Смотря где напишу. В некоторых, достаточно популярных языках, это сравнение, в некоторых присваивание, а в некоторых, возможно, эта операция переопределена.
grinCo
05.01.2019 21:08Берете одну книжку, нужную вам. В ней есть список литературы. Указываете эту книжку, и с десяток источников, перечисленных в ней самой. Если не хватает, берете в библиотеке пару книг из этого списка, открываете в конце – там опять список литературы, и тащите еще пару десятков названий. И так, пока не надоест.
Этот метод же не подходит ибо нужно ссылку на источник ставить после фразы которая взята из источника. Ну и в технических вузах список литературы спокойно может состоять из 3-5 пунктов.
opetrenko
05.01.2019 02:53+1— Это странный вопрос, Лена… Как меня может не устраивать система, созданная не мной?… Никаких оценок...
Еще более странный ответ.
Тем не менее «систему» он пытается менять.
Хм… Зачем?
Вообще, если вникнуть то Сергей просто выпендривается на фоне тупящей Лены. Но что он сказал по сути? То, что «системы» можно менять и некоторые этим злоупотребляют? Спасибо, Кэп. Размазать это на 20тыщ знаков — вот, где талант!
В остальном тексте Сергей сам не знает, чего он хочет.
Да, нарциссизм и ЧСВ его толкают «менять систему» походу рассказывая какие все тупые,
но что именно можно улучшить, какие методы проектирования и типовые решения существуют он, очевидно, даже не слышал.
А зачем? Сергей — писатель, а не жалкий читатель.
Жаль, что этот писатель не может даже с терминами опредилиться. То они не нужны — придумаем отсебятину, то потом они необходимы. Причем демагогия на эту тему — пол-интервью.
А вообще, Сергей свою задачу решает: на протяжение всей статьи уверенно и ритмично массажирует свое ЧСВ при этом используя ничтожно малое количество информации. Вот, где эффективность!1Tiger1
05.01.2019 12:38На самом деле, если внимательно почитать, Лена не особенно то и тупит: периодически указывает на противоречия в логике Сергея, поддакивает когда его начинает нести и он нервничает. Так ведут себя детские психологи, чтобы и проблему понять и ребенка в истерику не ввести или он в себе не замкнулся по принципу «никто меня не понимает». Или опытные журналисты, когда общаются с очень эксцентричными и зазвездившимися звездами, чтобы хоть какой-то материал для интервью добыть.
Автор, признавайтесь, серия рассказов написана для того чтобы некоторые люди в нашей профессии которые «словили звезду» могли посмотреть на себя со стороны и попытаться исправиться или хотя-бы прокачать софт скилы и научиться свой характер скрывать?nmivan Автор
05.01.2019 12:39у этой серии нет цели. Просто пишу, и все.
1Tiger1
05.01.2019 13:12Плохо когда у программиста нет цели, фигня обычно получается. Иногда сидишь смотришь в код, пытаешься понять «ну вот нафига тут это», а оказывается что просто так, программист развлекался, прочитал про новый паттерн и решил искорежить сложную архитектуру чтобы его применить. Потому что интересный и прикольный. А уж сколько раз я в ответ на вопрос «а почему вы решили использовать именно этот фреймворк/инструмент/базу данных?» слышал «ну хотелось попробовать», и все, это была единственная причина почему люди цепляли крылья с реактивными двигателями к комазу и пытались взлететь. Раз за разом. Даже если ничего не получалось. Упорно и настойчиво. К чужому камазу, который им завезли на техобслуживание и модернизацию, и который уже давно должен колесить по просторам страны перевозя грузы, но стоит в гараже и ожидает когда ему крылья на пропеллер поменяют потому что счас в моде квадракоптеры, а летающий камаз это круто.
Да и с писателями та же фигня. Сидишь иногда, думаешь, а что только что прочитал, что хотел сказать автор, может это я что-то не понял или проскочил, может тут можно действительно что-то полезное почерпнуть — а он просто писал и все, ничего он не собирался говорить, нет у него никакой цели, так троллит читателя когда нужно время убить и скучно, вот и пишет.VolCh
06.01.2019 18:25«Ну хотелось попробовать» как по мне получше «а я другого инструмента не знаю, только читал на Хабре». Откуда брать знания о том, что лучше подходит для нового проекта, если на предыдущих не пробовал разные альтернативы? Маркетинговым материалам верить?
DmitryOgn
05.01.2019 05:12Незаметных менеджера, программиста, техподдержку (когда система работает и не требует внимания) — увольняют как ненужных бездельников.
ИБД выигрывает, такова уж природа социума.
Характерный пример — чиновники/политики, в массе своей занимающиеся не решением проблем, а их созданием, чтобы оседлать «решение вопроса».
KirillGuzenko
05.01.2019 08:11Я этой хрени наелся еще в аспирантуре, когда на каждый чих надо искать источники, указывать номер страницы и год издательства, просто ради того, чтобы соблюсти некие выдуманные кем-то правила.
А давайте не будем пользоваться чужими наработками и библиотеками, придумывать свои названия и термины для всего, откажемся от стилистических и семантических паттернов в коде, ведь тогда людям будет очень весело и интересно разбираться в куче велосипедов! Зачем соблюдать некие выдуманные кем-то правила?
1Tiger1
05.01.2019 12:31Гениальным людям выдуманные другими правила, проведенные эксперименты и наработанный опыт — не нужны. Они гениальны и не могут ошибаться, а значит их мнение лучше всех остальных, даже кем-то там проверенным и чем-то подтвержденным. В такой ситуации сноски не нужны. Чужие библиотеки ущербны. Термины, паттерны и прочее нуждаются в изменении и творческой переработке. Как и любой код написанный другими людьми в переписывании с нуля. А система построенная другими по умолчанию ущербна и нуждается в изменении, ведь программист это тот кто меняет! И да, обычные негениальные программисты не должны лезть в код гениального, а значит и разбираться в нем им особо не нужно, так что стандарты действительно не нужны.
insideme
05.01.2019 12:05Жду выхода книги. Буду дарить всем знакомым директорам и собственникам бизнеса.
1Tiger1
05.01.2019 12:24-1Уважаемый автор. Напишите пожалуйста рассказ где Сергея сделали Самым Главным. Он разогнал всех ненужных людей. Повесил на дверь табличку «Гениальный Директор — Генеральный Программист». К нему ходили разные просители, кланялись, дары приносили, на коленях ползали. А он, после не такого уж долгого обьяснения какие они ничтожества и совсем не программисты, решал их проблемы мановением руки, делился своей мудростью и благословлял на хорошую работу. И чтобы они выходили за дверь и восхищенно закатывали глаза «ах какой мудрый человек, пропали бы мы без него», а двухкилометровая очередь у кабинета внимала и просила рассказать что изрек Сергей.
Джва года жду такого рассказа.
А если серьезно, можно поменять Сергею профессию? А то за профессию обидно. Слабовольный, постоянно чешет свое ЧСВ за счет принижения других, мизантроп, разводит философию без конкретики да еще на темы в которых ничего толком не понимает, противоречит сам себе, пытается натянуть автоматизированные процессы на процессы в которых задействованы люди и при этом постоянно жалуется что проблема в людях, они мешают, вот если бы не люди то все бы работало, а с ними процессы не работают потому что они не для людей.
Путь будет например таксидермистом. Их немного, на хабре точно, они сильно не обидятся.
И пусть научиться уже говорить «НЕТ». Вот представьте какой классный рассказ бы получился о лаконичности и принципиальной позиции:
— Сергей! Сергей!
Сергей встрепенулся, оторвался от компьютера и снял наушники. Сбоку стояла Лена, менеджер по снабжению, с какими-то бумагами в руках и вопросительно на него смотрела.
— Чего? – спросил Сергей.
— Интервью.
— Не хочу!
— Сергей, ну пожалуйста, это надо компании.
— Нет!
— Ну ладно, тогда пойду у Миши интервью возьму, пока.
— Пока.
Правда же прекрасно? Результат тот же, текст короче, Леночке не пришлось пол часа обтекать помоями которые щедро вываливал на нее и других Сергей, не пришлось сидеть демонстрируя внимание и при этом чертыхаясь про себя и про себя же повторяя «Держись Лена, ты профессионал, ты справишься, если взялась за дело надо его закончить, пусть и тошнит от пафоса этого Дартаньяна, воспринимай это как тренировку силы воли и умения общаться с людьми с трудными характерами, просто поддакивай, задавай глупые вопросы которые он ждет и давай такие же глупые ответы чтобы его ЧСВ радовалось, и записывай. Держи себя в руках, потом пойдешь в зал и грушу побьешь, а сейчас будь спокойна, участлива и улыбайся, не забывай улыбаться».
MayRiv
05.01.2019 12:29И почему ваш Сергей постоянно общается с картоном?
Просто прочитайте отдельно реплики собеседника, это же просто соломенного чучело, на котором автор оттачивает навыки убеждения.
digewu
05.01.2019 12:29//«зануда» mode on
Если написать код X = 2, что-то обязательно произойдет. А переменной X будет присвоено значение 2 тогда, когда написанный код будет «выполнен».
//«зануда» mode off
:)
calisto
05.01.2019 12:29А руководители, я прошу прощения, слишком зажрались. Формально – да, изменения – их основная работа.
Не понимаю зачем вводить сущности и что-то переизобретать, если изменениями занимается менеджмент, только из-за того что начальники слишком зажрались? Есть готовая профессия, специальности в университетах. Просто на руководящих должностях должны быть профессионалы, компетентные специально обученные люди.
Суть работы программиста – изменения. Никакая другая профессия из известных мне не стоит так же близко к изменениям, как программист.
Менеджмент всецело в изменениях, потому что нужно принимать постоянно управленческие решения в рамках неопределенности и в постоянно меняющейся окружающей среде.
1Tiger1
05.01.2019 13:00И Автор, пожалуйста, не путай молодежь.
Программист это человек который решает проблемы/задачи с помощью компьютеров. Чаще всего. Хотя полученные навыки и mindset позволяют в целом строить и модифицировать системы для решения задач и проблем. Даже системы состоящие только из людей и процессов (просто при этом нужно понимать отличия и особенности). Но этим уже не только программисты занимаются, тут можно десятки профессий притянуть. Поэтому оставим вариант «с помощью компьютеров».
И ключевое тут «задачи/проблемы». Программист должен четко понимать для чего он создает или меняет систему. При этом зная что абсолютного понимания нет на любом этапе ни у кого, потому что чаще всего программист работает в экспериментальных областях, каждое решение в чем то уникально, пусть и использует общие принципы. Вот умение построить/модифицировать систему (код, архитектуру, алгоритм) с необходимыми параметрами (гибкость, надежность, стабильность, скорость и пр.) для выполнения определенных задач, в условиях недостаточной информарованности (а часто и компетентности) и определяет уровень программиста, и является его основной задачей и основным умением. Фреймворки, языки, годы опыта — все это сопутствующее и не особо влияет на уровень. И принцип «работает — не трогай» не зря придуман, да он не абсолютен и не универсален, но он лучше «не нравиться — меняй». Более адекватная и запутанная формулировка «прежде чем что-то менять просчитай потенциальные проблемы которые принесут твои изменения, оцени риски, четко определи цели изменений и наметь план изменений, оцени стоит ли вносить эти изменения с учетом всех факторов и только тогда меняй, четко понимая что ты делаешь и зачем. Повторить процесс при изменении внешних данных или когда почувствуешь что узнал систему значительно лучше чем при предыдущем анализе». Ну за исключением когда риски небольшие и можно использовать изменения как эксперимент, с возможностью всегда быстро откатить систему в стабильное состояние.
А у вас программист тупо по определению должен все поменять, ну за исключением того что ему проще пережить чем менять (пример с универом). Ну то есть это человек который приходя на проект сразу кричит — все говно, все надо переделать, и переделывает, как ему нравиться, никого не слушая и не обращая внимания на стандарты, подходы, текущую архитектуру и без всяких целей и задач которые нужно решить этой переделкой, тупо потому что он программист и изменения — это его главная задача! Обычно команда гонит таких «гениев» погаными метлами, потому что вред от него превышает пользу и ломает всем работу.
V-core
06.01.2019 09:06Интересно в какой главе главный герой столкнётся с "человеческим фактором"?
Это в программе легко обойтись директивой Х=2, а в реальном мире каждому необходимо донести изменение и ещё пару раз проверить как поняли.andyudol
06.01.2019 14:05+1Это хорошо ещё, если просто не поняли, по глупости. А если как раз прекрасно поняли и сознательно вредят, причём умно?
Virgo_Style
06.01.2019 14:21Сергей вскользь употребил слово «модерируйте». Я бы к этому слову присмотрелся поближе. Модератор ведь именно тот, кто корректирует процесс, но не завязывает его на себя.
valis
А мне нравятся определения «бизнес архитектор» и «системный инженер», наверное первое несет меньше стереотипов. Вроде не пахнет пассивностью как у приставки «аналитик» и предполагает наличие знаний о методах воздействия на системы и полномочий на внесение изменений
nmivan Автор
Бизнес-архитектор, как и аналитик, отдает пассивностью относительно процесса непосредственного внедрения изменений. Он вроде как все придумал, нарисовал и убежал. Ну максимум — авторский надзор осуществляет. А когда ничего путного не выходит, говорит, что виноват прораб.
Системный инженер — сильно смахивает на системного администратора. Вроде как не доверишь ему, например, людьми руководить, или проектом изменений.
valis
Вот тут не согласен.
Архитектор как раз подразумевает активную позицию и прямую заинтересованность в переходе из системы из текущего в целевое состояние. В крупных компаниях есть бизнес архитекторы и я наблюдал за их работой иногда исполнял их роль.
Я работаю солюшен арихитектором, бизнес архитектора у нас нет. Напрямую не влияю на бизнес процессы, но косвенно все равно подталкиваю людей в нужное русло.
nmivan Автор
В одной из ненаписанных глав Сергей долго думал, как назвать свою профессию. Вариант с архитектором тоже рассматривал. Но у него, как вы заметили, все-таки присутствует какая-то странная привязанность к слову «программист», хоть он это и отрицает.
Жалко, что поспорить с ним нельзя — он же выдуманный персонаж.
napa3um
«Архитектор», в целом, подходящее определение, он действительно ответственен за конечный результат прежде всего, а какие там прорабы чего не допрорабили конечного заказчика уже волнует мало. Ещё можно из околоградостроительной темы привлечь слово «мэр» :). Из кинопроизводства можно взять слово «режиссёр» (а если перевести его на английский, получить директора :)). Ну и вообще, наконец, понять, что в разных бизнесах нужны разные качества руководителя в разных приоритетах, и директора, завязавшиеся всё на себя, исчезнут не от осознания важности изменений, а от экономической обратной связи, когда изменения станут выгоднее завязывания процессов на себя (Василий, возможно, с важным видом рассказывает как он очень занят, как ему не хватает времени на изменения, но домой он поедет на какой-нибудь дорогой машине, не очень соответствующей его окладу. Потому что именно он носитель ключей от бэкдора в систему заказа). Когда «меняющиеся» конторы станут вытеснять на рынке «стабильно-авральные», тогда и сбудутся пророчества руководителя-программиста из вашей сказки :). Руководитель-программист дошёл до неизбежности бюрократических ограничений, но пока не обобщил этот опыт до неизбежности более глобальных, экономических ограничений (а заработав пару десятков миллиардов долларов дойдя и до политических) :).
klirichek
"Архитектор" больше ассоциируется с чем-то фундаментальным и незыблемым, чем с изменениями. Спроектировал систему, может даже очень хорошую; её построили — и всё, дальше архитектор без работы.
Мэр — ну, опять же, англицизм "major" — майор, главный. Снова большой соблазн замкнуть все процессы на себя и заниматься поддержкой/согласованиями.
Режиссер и директор — не сильно отличаются в этом плане от мэра. У них у всех всё тот же недостаток — сваливание от первоначального "тушения пожара" в постоянное авральное пекло.
Тут скорее напрашивается что-то сельскохозяйственное — огородник или садовник. Вскопал, посадил, полил; когда нужно обработал от сорняков/вредителей — и наблюдает. А растёт всё само. Но при желании можно достаточно легко "переконфигурировать" систему. Например, выкинуть половину грядок с картошкой и посадить сельдерей. С очевидным показателем эффективности — чтобы было, что кушать в конце сезона.
napa3um
Думаю, эти лингвистические игры можно бесконечно продолжать, на вкус и цвет у всех метафоры разные, разное понимание акцентов. А в словарь в итоге попадёт слово, понравившееся пионеру или лидеру отрасли, а не соответствующее вашим (или моим) идеальным представлениям об этимологии. Главная мысль в моём комментарии, на который вы отвечаете, находится ближе к концу.
mSnus
А программист, если его взять в ипостаси быдлокодера… /sarcasm
farcaller
Так выдумайте сцену где вы пришли к нему и спорите, делов то. Вы же его характер знаете — значит знаете "что бы на это ответил Сергей".
valis
Не, в споре о терминологии наш персонаж бы не участвовал.
Я бы его лучше закинул в такую ситуацию, когда реально нужны правильные и общепринятые на рынке термины. Например создание подразделения, которое должно продвигать изменения в бизнесе и системах аля проектный офис или поиск человека с такими скилами
hard_sign
Эх, поймать бы дурака,
Да намять ему бока…
Да у нас спокон веков
Нет суда на дураков!
©
Mikluho
napa3um
А как иначе-то?
valis
Да я видел и других, но не долго таких видел :-)
А проекты, с которых архитектор линял после разработки решения обычно взлетали с таким скрипом и не разлетались в полете благодаря какому-то чуду и куче костылей.
slovak
Системный инженер никаким образом не "попахивает" системным администратором. Более того, то, что большинство понимает под "системный администратор" на самом деле называется "инженер по эксплуатации" и к системной инженерии никакого отношения не имеет. Рекомендую глянуть на вики, что такое системная инженерия, вы будете удивлены.
sergix
сразу вспомнился анекдот, точный текст не передам. Но он как раз в духе Сергея :D САБЖ:
Говорил знакомым, что работаю программистом, каждый день звонили и просили починить комп, решил говорить что архитектор программ, недавно позвонил друган попросил начертить ему проект сартира