Комментарии 101
А мне нравятся определения «бизнес архитектор» и «системный инженер», наверное первое несет меньше стереотипов. Вроде не пахнет пассивностью как у приставки «аналитик» и предполагает наличие знаний о методах воздействия на системы и полномочий на внесение изменений
Бизнес-архитектор, как и аналитик, отдает пассивностью относительно процесса непосредственного внедрения изменений. Он вроде как все придумал, нарисовал и убежал. Ну максимум — авторский надзор осуществляет. А когда ничего путного не выходит, говорит, что виноват прораб.
Системный инженер — сильно смахивает на системного администратора. Вроде как не доверишь ему, например, людьми руководить, или проектом изменений.
Системный инженер — сильно смахивает на системного администратора. Вроде как не доверишь ему, например, людьми руководить, или проектом изменений.
Вот тут не согласен.
Архитектор как раз подразумевает активную позицию и прямую заинтересованность в переходе из системы из текущего в целевое состояние. В крупных компаниях есть бизнес архитекторы и я наблюдал за их работой иногда исполнял их роль.
Я работаю солюшен арихитектором, бизнес архитектора у нас нет. Напрямую не влияю на бизнес процессы, но косвенно все равно подталкиваю людей в нужное русло.
Архитектор как раз подразумевает активную позицию и прямую заинтересованность в переходе из системы из текущего в целевое состояние. В крупных компаниях есть бизнес архитекторы и я наблюдал за их работой иногда исполнял их роль.
Я работаю солюшен арихитектором, бизнес архитектора у нас нет. Напрямую не влияю на бизнес процессы, но косвенно все равно подталкиваю людей в нужное русло.
В одной из ненаписанных глав Сергей долго думал, как назвать свою профессию. Вариант с архитектором тоже рассматривал. Но у него, как вы заметили, все-таки присутствует какая-то странная привязанность к слову «программист», хоть он это и отрицает.
Жалко, что поспорить с ним нельзя — он же выдуманный персонаж.
Жалко, что поспорить с ним нельзя — он же выдуманный персонаж.
«Архитектор», в целом, подходящее определение, он действительно ответственен за конечный результат прежде всего, а какие там прорабы чего не допрорабили конечного заказчика уже волнует мало. Ещё можно из околоградостроительной темы привлечь слово «мэр» :). Из кинопроизводства можно взять слово «режиссёр» (а если перевести его на английский, получить директора :)). Ну и вообще, наконец, понять, что в разных бизнесах нужны разные качества руководителя в разных приоритетах, и директора, завязавшиеся всё на себя, исчезнут не от осознания важности изменений, а от экономической обратной связи, когда изменения станут выгоднее завязывания процессов на себя (Василий, возможно, с важным видом рассказывает как он очень занят, как ему не хватает времени на изменения, но домой он поедет на какой-нибудь дорогой машине, не очень соответствующей его окладу. Потому что именно он носитель ключей от бэкдора в систему заказа). Когда «меняющиеся» конторы станут вытеснять на рынке «стабильно-авральные», тогда и сбудутся пророчества руководителя-программиста из вашей сказки :). Руководитель-программист дошёл до неизбежности бюрократических ограничений, но пока не обобщил этот опыт до неизбежности более глобальных, экономических ограничений (а заработав пару десятков миллиардов долларов дойдя и до политических) :).
"Архитектор" больше ассоциируется с чем-то фундаментальным и незыблемым, чем с изменениями. Спроектировал систему, может даже очень хорошую; её построили — и всё, дальше архитектор без работы.
Мэр — ну, опять же, англицизм "major" — майор, главный. Снова большой соблазн замкнуть все процессы на себя и заниматься поддержкой/согласованиями.
Режиссер и директор — не сильно отличаются в этом плане от мэра. У них у всех всё тот же недостаток — сваливание от первоначального "тушения пожара" в постоянное авральное пекло.
Тут скорее напрашивается что-то сельскохозяйственное — огородник или садовник. Вскопал, посадил, полил; когда нужно обработал от сорняков/вредителей — и наблюдает. А растёт всё само. Но при желании можно достаточно легко "переконфигурировать" систему. Например, выкинуть половину грядок с картошкой и посадить сельдерей. С очевидным показателем эффективности — чтобы было, что кушать в конце сезона.
Думаю, эти лингвистические игры можно бесконечно продолжать, на вкус и цвет у всех метафоры разные, разное понимание акцентов. А в словарь в итоге попадёт слово, понравившееся пионеру или лидеру отрасли, а не соответствующее вашим (или моим) идеальным представлениям об этимологии. Главная мысль в моём комментарии, на который вы отвечаете, находится ближе к концу.
А программист, если его взять в ипостаси быдлокодера… /sarcasm
Жалко, что поспорить с ним нельзя — он же выдуманный персонаж.
Так выдумайте сцену где вы пришли к нему и спорите, делов то. Вы же его характер знаете — значит знаете "что бы на это ответил Сергей".
Не, в споре о терминологии наш персонаж бы не участвовал.
Я бы его лучше закинул в такую ситуацию, когда реально нужны правильные и общепринятые на рынке термины. Например создание подразделения, которое должно продвигать изменения в бизнесе и системах аля проектный офис или поиск человека с такими скилами
Я бы его лучше закинул в такую ситуацию, когда реально нужны правильные и общепринятые на рынке термины. Например создание подразделения, которое должно продвигать изменения в бизнесе и системах аля проектный офис или поиск человека с такими скилами
Жалко, что поспорить с ним нельзя — он же выдуманный персонаж.
Эх, поймать бы дурака,
Да намять ему бока…
Да у нас спокон веков
Нет суда на дураков!
©
активную позицию и прямую заинтересованность в переходе из системы из текущего в целевое состояниеэто где же вы видели таких архитекторов, которые бы не только разрабатывали/согласовывали архитектуру, но и усиленно её внедряли? :)
Системный инженер никаким образом не "попахивает" системным администратором. Более того, то, что большинство понимает под "системный администратор" на самом деле называется "инженер по эксплуатации" и к системной инженерии никакого отношения не имеет. Рекомендую глянуть на вики, что такое системная инженерия, вы будете удивлены.
сразу вспомнился анекдот, точный текст не передам. Но он как раз в духе Сергея :D САБЖ:
Говорил знакомым, что работаю программистом, каждый день звонили и просили починить комп, решил говорить что архитектор программ, недавно позвонил друган попросил начертить ему проект сартира
Говорил знакомым, что работаю программистом, каждый день звонили и просили починить комп, решил говорить что архитектор программ, недавно позвонил друган попросил начертить ему проект сартира
Если нужна терминология для участников процесса создания и сопровождения систем, то зачем изобретать велосипед? Есть отрасль, существующая больше 4х тысяч лет и которая все это время и занимается созданием и сопровождением систем… строительство. Конечно не созданием, а строительством, не сопровождением, а обслуживанием (очень давно, уже в другом государстве система ЖКУ была подчинена МинСтрою). Ну и брать оттуда роли да термины, ну может немного их «отполировать»…
Читаю с интересом, а вот про диссертацию не мог пройти мимо.
когда на каждый чих надо искать источники, указывать номер страницы и год издательства, просто ради того, чтобы соблюсти некие выдуманные кем-то правила.
Ссылки на источники должны быть раскиданы по тексту. Есть тезис — есть номер источника. Если в конце просто список источников, случайно собранный — это, конечно, мусор.
Зачем вообще нужны ссылки на источники? Что бы читатель мог узнать, существует ли то, что написано или оно выдумано. Если написано без ссылки, например, что "люди переоценивают малые вероятности (считают, что они больше, чем на самом деле)" — нужно или верить на слово или проводить свое исследование. Но наука так не может работать — нельзя верить всем на слово, потому что шарлатанам "попрёт карта".
Поэтому все и должны либо ссылаться на результат эксперимента (с описанием методологии), либо на чужое исследование (надёжность которого можно проверить).
Что бы читатель мог узнать, существует ли то, что написано или оно выдумано
все верно, только у героя этого текста нет читателей. Поэтому стараться не для кого.
А вот результат есть кому почитать.
Я к тому, что у правила есть смысл и цель. И рандомно набранные источники в списке литературы возникают потому, что некоторые преподы не знают, в чем этот смысл состоит или им плевать.
Соблюдать же это правило, когда читателей нет — действительно нет смысла. Вполне достаточно проверить для себя.
У вас в слове почитать ошибка — правильно посчитать!
> Что бы читатель мог узнать, существует ли то, что написано или оно выдумано.
Проблема в том, что в подавляющем среднем эти ссылки и факты никто не проверяет. Никому не интересно (проверено грустной практикой написания научных работ и дисера).
А шарлатанам, увы, карта и так прет. По моим наблюдениям, основным фильтром в науке остается не соблюдение формальных правил, а добросовестность научных руководителей. Т.е. проверка идет не фактов, а принадлежности к той или иной научной структуре и подтверждений компетентности от старших товарищей.
> Я, как дурак, потом сел и написал все методы, которые применил – с названиями, отсылками, номерами страниц и цитатами. Кто его читал?
— Кто?
— Никто.
Проблема в том, что в подавляющем среднем эти ссылки и факты никто не проверяет. Никому не интересно (проверено грустной практикой написания научных работ и дисера).
А шарлатанам, увы, карта и так прет. По моим наблюдениям, основным фильтром в науке остается не соблюдение формальных правил, а добросовестность научных руководителей. Т.е. проверка идет не фактов, а принадлежности к той или иной научной структуре и подтверждений компетентности от старших товарищей.
> Я, как дурак, потом сел и написал все методы, которые применил – с названиями, отсылками, номерами страниц и цитатами. Кто его читал?
— Кто?
— Никто.
Честно, не знаю, как работает наука в России и работает ли вообще. Лично я ссылки проверяю.
В декабре прочитал две книги — биохакинг мозга, Дэйва Эспри и "думай медленно, решай быстро", Даниэля Канемана. У обоих есть источники. Но Эспри подтверждает свои утверждения ссылками на глянцевые журналы, Канеман — на слепые рандомизированные исследования. После третьей случайной ссылки у Канемана я перестал проверять — всему, что он написал, можно верить, фактически, на слово. Не потому, что он умный или принадлежит к какой-то научной школе, а потому, что он сам всем подряд на слово не верит. Конечно, часть исследований сделана по стандартам семидесятых (слишком маленькие группы, например), но взятых совсем с потолка утверждений у него нет.
подтверждений компетентности от старших товарищей
Это подтверждение того, как человек работает с источниками. Если он хоть иногда берет данные с Пикабу, то копаться в его работах — трата времени (та самая ложка говна в бочке меда). Но для этого нужно знать, откуда он берет данные, верно? А что бы убедиться, что он не набрал источников случайно, они и должны быть привязаны к местам в тексте. Так можно проверить за вменяемое время.
проверено грустной практикой написания научных работ и дисера
Если ваша научная работа собирается изменить индустрию или по масштабам тянет на Нобелевскую — всё будет проверено. Не каждым читателем, но каждым сотым. Если же работа в целом проходная (такие тоже иногда нужны, я не имею ввиду что-то обидное) и читателей у неё вряд ли будет больше двух — то неудивительно. Весь вопрос, какое научное значение для других вы сами вкладываете в свою работу. Если оно небольшое, то источниками/методологией экспериментов можно пренебречь.
> Лично я ссылки проверяю.
Вы существуете! :)
Серьезно, я очень рад, что кто-то обращает на такие вещи внимание. Увы, проверка занимает много времени, и почти никто этим не занимается.
В принципе, согласен — наличие источников позволяет убедиться, что человек берет данные не с потолка. Как вы правильно указываете, смысл в этом правиле действительно есть.
Увы, как я уже говорил, это скорее формальный фильтр, который работает плохо. В большую часть работ (хорошо, мы сейчас говорим про области типа программирования и психологии) можно добавить ссылки путем копирования библиографии какой-нибудь статьи по схожей теме. Ну, или банально просмотреть указанные источники и добавить то, что более-менее релевантно. Т.е. для недобросовестного исследователя это работу усложнит не сильно, а вот добросовестному — сильно.
И еще. Часто основополагающие работы («меняющие индустрию») ссылаются не на такое большое число источников, и обладают не столь внушительной статистикой. В пример можно привести работу Маслоу «Мотивация и личность». Он сам говорит, что выборка по статистическим меркам у него смешная (в районе 10 реальных людей и 10 исторических личностей, точно сейчас не скажу); и, например, он сам признает что в этом смысле проигрывает в сравнении с бихевиористами, которые занимали главенствующие позиции в психологии в США в это время.
Другой пример важной научной работы, которую «никто не удосужился проверить» — реакция Белоусова — Жаботинского (историю можно глянуть в Википедии, важнейший факт просто никто не удосужился проверить).
В общем, не все так просто с источниками, статистикой и научной работой.
Вы существуете! :)
Серьезно, я очень рад, что кто-то обращает на такие вещи внимание. Увы, проверка занимает много времени, и почти никто этим не занимается.
В принципе, согласен — наличие источников позволяет убедиться, что человек берет данные не с потолка. Как вы правильно указываете, смысл в этом правиле действительно есть.
Увы, как я уже говорил, это скорее формальный фильтр, который работает плохо. В большую часть работ (хорошо, мы сейчас говорим про области типа программирования и психологии) можно добавить ссылки путем копирования библиографии какой-нибудь статьи по схожей теме. Ну, или банально просмотреть указанные источники и добавить то, что более-менее релевантно. Т.е. для недобросовестного исследователя это работу усложнит не сильно, а вот добросовестному — сильно.
И еще. Часто основополагающие работы («меняющие индустрию») ссылаются не на такое большое число источников, и обладают не столь внушительной статистикой. В пример можно привести работу Маслоу «Мотивация и личность». Он сам говорит, что выборка по статистическим меркам у него смешная (в районе 10 реальных людей и 10 исторических личностей, точно сейчас не скажу); и, например, он сам признает что в этом смысле проигрывает в сравнении с бихевиористами, которые занимали главенствующие позиции в психологии в США в это время.
Другой пример важной научной работы, которую «никто не удосужился проверить» — реакция Белоусова — Жаботинского (историю можно глянуть в Википедии, важнейший факт просто никто не удосужился проверить).
В общем, не все так просто с источниками, статистикой и научной работой.
В большую часть работ(...) можно добавить ссылки путем копирования библиографии какой-нибудь статьи по схожей теме.
Странно, в требованиях к магистерской диссертации, которую защитил летом, было одно из основных требований к списку литературы — на каждый элемент списка должна присутствовать ссылка в тексте. Просто так «скопипастить» это требование не позволяло.
Я лично, если что интересное пишут со ссылкой на источник, обязательно найду и почитаю сам источник. Редко но бывает, что в источнике все уже не так интересно как было в его вольном пересказе :)))
А про ссылки на литературу конечно есть проблема что они обязательно должны быть в количестве Х+ (где Х зависит от вида работы: диплом, статья или кандидатская), но обычно это не сложно: берется работа по теме (желательно зарубежная там с источниками получше) и переписывается из нее введение в котором делают анализ того что было сделано по этой теме вместе с источниками (понятное дело что оставляешь только нужное). А вообще по хорошему если занимаешься темой то и так знаешь все ссылки и схожие работы.
важнейший факт просто никто не удосужился проверить
Перепроверять эксперименты в десятки раз сложнее, чем их описания. Я проверяю только формальное описание, размер группы, методологию. Сам эксперимент конечно не провожу повторно, это неподъемная сложность для меня.
И эта проблема совсем другого рода. Откинуть факт, потому что лень проверять — это не то же самое, что принять что-то за факт, потому что лень проверять.
Оффтоп
Что бы читатель мог узнать, существует ли то, что написано или оно выдумано.
:)
Я где-то слышал, что придумали целую лженауку по управлению, кибернетику кажется. Похоже, что ее вот-вот переизобретут.
кажется, героя этого текста наука не особо интересует. Равно как и ее научность, или лженаучность.
Что-то я не слышал, чтобы кибернетика помогла кому-нибудь управлять хотя бы лыжами.
Нейросетки всех сортов и прочие альфы-го — как раз отпрыски той самой кибернетики. Прежде всего.
Лыжи — это не хотя бы. Это система, для управления которой человек хорошо заточен (потому что заточен управлять своим телом). Вот управлять самолётом — другое дело. Человек на это не заточен, поэтому роботы уже справляются не хуже. Лыжи тоже освоят, но значительно позже. К тому же не видно коммерческой пользы, это тоже снижает приоритет.
В управлении лыжным курортом может и помочь.
Кибернетику уже раза четыре переизобретали на моей памяти, коммунизм — шесть.
про шесть коммунизмов интересно, кто и когда? Вроде ж основополагающий принцип «штуками для производства всего-всего (заводами, шахтами, нефтяными вышками, электростанциями, землей, железными и асфальтовыми дорогами и прочим в этом духе) владеет все общество, а не какие-то частные руки» никем не переизобретался.
кибенематика ))
del
Видимо сейчас удобно пополнить список анонимных вопросов для следующей части )))
Анонимный вопрос — принесет ли пользу практика, чтобы руководители иногда работали наравне со своими сотрудниками, чтобы не терять связи с реальностью?
Анонимный вопрос — принесет ли пользу практика, чтобы руководители иногда работали наравне со своими сотрудниками, чтобы не терять связи с реальностью?
тсс, не выдавайте моих секретов.
Зависит от рода деятельности и от поставленных исследовательских (архитектурных) задач. Машинисту быть колесом тепловоза раз в неделю, очевидно, бесполезно. А сама постановка цели «чтобы не терять связь с реальностью» говорит о приоритетах процессов поддержки существующей системы перед процессами разработки (изменений). По сути вы из разработчиков пытаетесь сделать сотрудников колцентра, и чтобы они сами вместо директора делали работу по обобщению проблем и формирования направления изменений. Эдакий «менеджмент для бедных» или «я у мамы эффективный менеджер». Если бизнес постоянно горит, что всем нужна постоянная «связь с реальностью», то лучше пересмотреть процессы и кадровую сетку, а не пытаться играть в президента банановой республики.
Давным давно в очень далекой галактике евангелистов упрекали в потере связи с реальностью, теперь про евангелистов не слышно. Много лет и столетий, руководство всех мастей упрекают в отсутствии адекватной оценки трудозатрат подчиненных и представлений об «узких» местах.
Да и среди руководителей, мало кто не согласится с утверждением, что если все хорошо, то не факт, что оно так и есть. Как и среди автобиографических книг великих людей можно найти вечный поиск проблем, а без «спускания с небес», это проделать невозможно.
Да и среди руководителей, мало кто не согласится с утверждением, что если все хорошо, то не факт, что оно так и есть. Как и среди автобиографических книг великих людей можно найти вечный поиск проблем, а без «спускания с небес», это проделать невозможно.
Эту тему можно мусолить вечно, если продолжать говорить беспредметными идеалистическими утверждениями. В каждом конкретном случае есть своя цена обучения горе-руководителя, «оторванного от реальности» (и свои причины этой оторванности). Мой поинт в том, что изоляция компетенций и зон ответственности в общем случае (я бы даже сказал в большинстве случаев) может быть не только вредной, но и полезной, в зависимости от масштабов предприятия (чем компания больше, тем это проявляется ярче). И проблемы изоляции должны указывать не на проблемы самого принципа divide et empire, а, возможно, на низкий уровень компетенции того самого архитектора (или кто там его роль на себя берёт), производящего divide. И эту низкую компетенцию как раз и пытаются компенсировать, порою, «самоорганизацией», сваливанием на исполнителей проблем руководства и размазыванием (а по сути — вымыванием) ответственности путём тотального «горизонтального связывания» всех со всеми. «Не понимаю, как должно работать предприятие, но я соберу лучших специалистов, дам им между собой договориться и посмотрю, что получится. Если не повезёт — уволю, ведь не моя вина, что они не сработались.»
Если упрощать, то не нужно сваливать на одну роль сразу два типа ответственности за один локальный процесс — стратегическую и тактическую. Да, трудно формально разделить стратегию и тактику, но опытный руководитель это видит и понимает, как может возникнуть конфликт интересов при смешивании этих двух уровней. Конечно, менеджмент — штука очень фундаментальная и глубокая, и некомпетентность в этой теме проще компенсировать вариантом «поработаю за станком, как мои ребята» (или «пусть ребята займутся погрузкой деталей, которые они вытачивают»), чем получением соответствующего образования.
Если упрощать, то не нужно сваливать на одну роль сразу два типа ответственности за один локальный процесс — стратегическую и тактическую. Да, трудно формально разделить стратегию и тактику, но опытный руководитель это видит и понимает, как может возникнуть конфликт интересов при смешивании этих двух уровней. Конечно, менеджмент — штука очень фундаментальная и глубокая, и некомпетентность в этой теме проще компенсировать вариантом «поработаю за станком, как мои ребята» (или «пусть ребята займутся погрузкой деталей, которые они вытачивают»), чем получением соответствующего образования.
Как по мне, то крайне редко это однозначную пользу будет приносить, если её брать позиции, где управление и прочее обеспечение работ не требует много времени, типа бригады грузчиков или отделочников. Стереотипный тимлид разработчиков, да не дай бог в кроссфункциональной команде — уже под сомнением по умолчанию, если не делегировать управленческие полномочия другим членам команды.
Если дойти до маразма, то этот руководитель будет согласовывать каждое пересылаемое письмо.
— Ну, это и правда маразм…
— Пример утрированный, но суть ведь ясна?
вы мою предыдущую работу описали, и руководителя со штатом >3000 человек, и это реальность, а не утрированный пример
чаще для этого ставят докс вижн, нанимают программиста для его обслуживания, а потом ещё вместо того, чтобы сделать, сидят и мусолят, какой должен быть правильный маршрут для создания служебки на это изменения(причем когда оно будет внесено, оно будет не актуально, и пострадает опять же выручка).
или меняют работу :) так как тратить свою жизнь на это — бессмысленно
для региона и семьей — опасно Ваше предложение.
Для семьи гораздо опаснее оставаться, так как внезапно выпав из данной системы, с навыками заточенными только под нее — найти что-то другое будет гораздо сложнее, дольше и болезненнее. Впрочем, для сварщика, например, это неактуально, но для них и проблем таких нет, это скорее проблемы среднего уровня. А для высшего менеджмента проблема узкой специализации под систему есть всегда.
А я называю ето магией. Дано: ситуация А, надо: ситуация Б, что делать? Магию. Я работал когда-то "просто програмистом" и когда понял, что моих программ ну крайне недостаточно взял и всю систему в компании переделал чтоб у всех меньше пожаров было, а у меня больше свободного от пожарогашения времени. А мой тогдашный начальник так и не понял меня, когда я сказал ему, что я у него работаю волшебником в голубом вертолете. "Да не нужны мне никакие волшебники, мне нужны нормальные работники, у которых есть четкое рабочее время и четкий ответ на вопрос "Когда будет готово?". Вот и остались сейчас у него одни четкие работники да что-то дела у него напоследок вообще никак.
Магия (неформализованное прямое управление) как противоположность тотальной бюрократии — тоже беда. А Истинный Путь, как водится, пролегает где-то посерединке, между тотальным программированием (бюрократизацией) и тотальной магической свободой без ролей и зон ответственности. И путь этот приходится каждый раз заново искать, Универсального Ответа не существует. Чувство меры, разумный выбор — то, что приходится (к сожалению романтичных программистов) всё ещё делегировать несовершенным людям.
Вопрос «когда будет готово?» перекрывает вопросы управления и автоматизации со всеми их составляющими. Автоматизатору от этого грустно. Впрочем, стоит признать, это же спасает от неправильной автоматизации (т.е., делаемой людьми с таким же примитизированным и решительным подходом).
Системность — это всегда сложнее, чем можно себе представить.
Публикация потенциально интересная, давно ничего не читал по этой теме, а здесь и суждения знающего специалиста, и изложение способного к литературе. Однако — как мы испортились — ни сохранить, ни кому-то порекомендовать не захочу. Зачем было наполнять нелитературными выражениями…
Публикация потенциально интересная, давно ничего не читал по этой теме, а здесь и суждения знающего специалиста, и изложение способного к литературе. Однако — как мы испортились — ни сохранить, ни кому-то порекомендовать не захочу. Зачем было наполнять нелитературными выражениями…
На счёт списков литературы автор погорячился. Это должен быть самый важный раздел в статье или книге если ты инженер, т.к. тебе приходится время от времени изучать новый материал и если возникают сомнения, первым делом лезешь именно в этот список, чтобы посмотреть на что опирался автор при создании материала. практика — интереснее, но подкреплённая теорией — эффективнее и надёжнее. это помогает уменьшить количество магии, танцев с бубнами и прочей изотерики в создаваемой тобой системе.
Зависит от целевой аудитории статьи или книги.
Тоже согласен что от целевой аудитории зависит.
Если отрасль сильно регламентирована — например медицинский центр — то без ссылок на нормативные документы не обойдешься. Или если сильно зависит от технологии — тогда тоже надо ссылки давать на мануал или технологические режимы.
А если писать для небольшой студии вебдизайна, то скорее всего на список глянут только из любопытства да желания пошутить на тему.
В целом надо оценить риски того, что будет и с какой вероятностью если не проработаны источники данных, т.е. список литературы. Если риски минимальны — не надо писать, так как зря время теряем. Если риски велики по вероятности или последствиям, или тем более и по тому и по другому — надо обязательно. Времени не так уж много занимает, а очень многие риски будут минимизированы.
Если отрасль сильно регламентирована — например медицинский центр — то без ссылок на нормативные документы не обойдешься. Или если сильно зависит от технологии — тогда тоже надо ссылки давать на мануал или технологические режимы.
А если писать для небольшой студии вебдизайна, то скорее всего на список глянут только из любопытства да желания пошутить на тему.
В целом надо оценить риски того, что будет и с какой вероятностью если не проработаны источники данных, т.е. список литературы. Если риски минимальны — не надо писать, так как зря время теряем. Если риски велики по вероятности или последствиям, или тем более и по тому и по другому — надо обязательно. Времени не так уж много занимает, а очень многие риски будут минимизированы.
…стоит в стороне от системы и меняет ее…
Это называется бог.
Можно даже уточнить класс бога — демиург :).
Условно можно и так, только, действительно, с маленькой буквы.
По науке, исчерпывающе описать систему понятиями и средствами самой этой системы невозможно; поэтому для категории «сложная система» уместно предполагать участие вышеестественного; в случае же обыкновенного предприятия быть вне/над системой — это всего лишь привлекать еще не использованные знания и средства и иметь делегированные от владельца права.
По науке, исчерпывающе описать систему понятиями и средствами самой этой системы невозможно; поэтому для категории «сложная система» уместно предполагать участие вышеестественного; в случае же обыкновенного предприятия быть вне/над системой — это всего лишь привлекать еще не использованные знания и средства и иметь делегированные от владельца права.
У нас в компании уже год как есть начальник производства и зам.директора по развитию производства.
На 100% не совпадает с определением Сергея, но общая мысль при таком разделении обязанностей была аналогичная.
В подчинении у начальника производства — линейные мастера и рабочие, а в подчинении зам.директора по развитию производства — конструктора, технологи конструкторского отдела, производственные технологи и частично программисты.
Разница в том что система по статье это система управления, а у нас система производства. Т.е. включает в себя не только управление, но и технологию производства. Однако в целом есть очень много чего похожего.
По итогам года работы в такой системе я сделал следующие выводы:
1. Система имеет право на жизнь, но есть ряд особенностей которые надо учитывать при ее внедрении(см.следующие пункты).
2. Необходимо добиться совместной работы линейного руководителя и руководителя по развитию. Для этого как минимум нужна единая система мотивации — чтобы не было так, что для одного хорошо, то для другого плохо. Например для линейного мотивация только от объема, а для развивающего бонус от выполненного проекта. При выполнении проекта объем может упасть, так как производятся изменения. В итого краткосрочно линейный страдает и между ними происходит конфликт. Если давать бонус за проект, то обоим, если давать процент от оборота, то тоже обоим. И естественно они должны работать как напарники — у нас они в одном кабинете сидят за соседними столами и на производственных планерках оба присутствуют.
3. Очень желательно, чтобы руководитель по развитию имел своих подчиненных и некоторые смежные обязанности, а не просто только обязанность менять(развивать) систему. Во первых далеко не всегда требуется менять систему, иногда у него будет свободное время и это не даст ему простаивать. Во вторых когда у развивающего нет подчиненных у него слегка меняется мировоззрение, он работает во многом как исполнитель и ему сложнее найти общий язык с линейным (как в плане снижения авторитета как руководителя — подчиненных то нет, так и в плане радикализации идей с персоналом — когда у тебя самого нет в подчинении никого — значительно проще давать радикальные советы — мол этого уволь, а нового возьми) и в любом случае у развивающего должен быть опыт более менее успешного руководства более чем 3 людьми (то есть опыт найма, обучения, решения конфликтов и т.п.).
Не говоря уже о том, что редкий генеральный пропустит идею взять человека только на то чтобы менять систему))) По мировоззрению генерального развивающий это человек с высокой зарплатой и его простой или недозагрузка это серьезные издержки. Поэтому загрузить руководительской текучкой на 25-50% это нормально и правильно.
4. На должность развивающего нужно ставить человека любящего изменения. Того, у которого есть внутренняя мотивация на изменения, если такой мотивации нет — человек не подходит для должности. Он может быть технически супер квалифицирован, иметь свежий взгляд, но если он не хочет искать что можно улучшить — работа не будет сделана. Пока этот человек сам не захочет. Это как с художником — он должен хотеть рисовать, если он умеет рисовать, но не хочет(творческий кризис в эту же тему) — это не профессионал художник, а любитель с непредсказуемым результатом.
5. Важна позиция руководства над линейным и развивающим. Раз в неделю, месяц и/или квартал — делать совместное совещание по модернизации системы. Кто за что отвечает, кто что делал, какие есть мысли по итогу работ за этот период, какие предложения по работе на следующий период. Пускать изменение системы на самотек(то ест на откуп линейному и развивающему) генеральному нельзя. Иначе очень сильно теряется эффективность — линейному очень сложно расставить приоритеты — что важнее выполнить текущую работу или выполнять мероприятия по изменению систему, а развивающему сложно потому что линейный ему не подотчетен и отвечать за выполнение работ он должен только перед вышестоящим.
6. По подчиненности — линейный и развивающий оптимально должны быть на одной ступени иерархии.
Развивающий не может подчиняться линейному — яйца курицу не учат(исключительный случай — линейный хочет сам научится и сам берет к себе такого человека — но это огромнейшая редкость — иногда так поступает генеральный-собственник, когда понимает что ему не хватает знаний).
Линейный может подчиняться развивающему, только если развивающий является генеральным или обособленным руководителем филиала, дивизиона или продукта с персональной ответственностью за результат.
Если интересно, то могу написать статью, где более подробно описать подобную систему и опыт ее внедрения. Только не знаю необходимо ли это на хабре. Все таки это систему управления c IT связано лишь косвенно. Коллеги дайте, пожалуйста, ответ в комментариях — писать статью или нет? Спасибо.
На 100% не совпадает с определением Сергея, но общая мысль при таком разделении обязанностей была аналогичная.
В подчинении у начальника производства — линейные мастера и рабочие, а в подчинении зам.директора по развитию производства — конструктора, технологи конструкторского отдела, производственные технологи и частично программисты.
Разница в том что система по статье это система управления, а у нас система производства. Т.е. включает в себя не только управление, но и технологию производства. Однако в целом есть очень много чего похожего.
По итогам года работы в такой системе я сделал следующие выводы:
1. Система имеет право на жизнь, но есть ряд особенностей которые надо учитывать при ее внедрении(см.следующие пункты).
2. Необходимо добиться совместной работы линейного руководителя и руководителя по развитию. Для этого как минимум нужна единая система мотивации — чтобы не было так, что для одного хорошо, то для другого плохо. Например для линейного мотивация только от объема, а для развивающего бонус от выполненного проекта. При выполнении проекта объем может упасть, так как производятся изменения. В итого краткосрочно линейный страдает и между ними происходит конфликт. Если давать бонус за проект, то обоим, если давать процент от оборота, то тоже обоим. И естественно они должны работать как напарники — у нас они в одном кабинете сидят за соседними столами и на производственных планерках оба присутствуют.
3. Очень желательно, чтобы руководитель по развитию имел своих подчиненных и некоторые смежные обязанности, а не просто только обязанность менять(развивать) систему. Во первых далеко не всегда требуется менять систему, иногда у него будет свободное время и это не даст ему простаивать. Во вторых когда у развивающего нет подчиненных у него слегка меняется мировоззрение, он работает во многом как исполнитель и ему сложнее найти общий язык с линейным (как в плане снижения авторитета как руководителя — подчиненных то нет, так и в плане радикализации идей с персоналом — когда у тебя самого нет в подчинении никого — значительно проще давать радикальные советы — мол этого уволь, а нового возьми) и в любом случае у развивающего должен быть опыт более менее успешного руководства более чем 3 людьми (то есть опыт найма, обучения, решения конфликтов и т.п.).
Не говоря уже о том, что редкий генеральный пропустит идею взять человека только на то чтобы менять систему))) По мировоззрению генерального развивающий это человек с высокой зарплатой и его простой или недозагрузка это серьезные издержки. Поэтому загрузить руководительской текучкой на 25-50% это нормально и правильно.
4. На должность развивающего нужно ставить человека любящего изменения. Того, у которого есть внутренняя мотивация на изменения, если такой мотивации нет — человек не подходит для должности. Он может быть технически супер квалифицирован, иметь свежий взгляд, но если он не хочет искать что можно улучшить — работа не будет сделана. Пока этот человек сам не захочет. Это как с художником — он должен хотеть рисовать, если он умеет рисовать, но не хочет(творческий кризис в эту же тему) — это не профессионал художник, а любитель с непредсказуемым результатом.
5. Важна позиция руководства над линейным и развивающим. Раз в неделю, месяц и/или квартал — делать совместное совещание по модернизации системы. Кто за что отвечает, кто что делал, какие есть мысли по итогу работ за этот период, какие предложения по работе на следующий период. Пускать изменение системы на самотек(то ест на откуп линейному и развивающему) генеральному нельзя. Иначе очень сильно теряется эффективность — линейному очень сложно расставить приоритеты — что важнее выполнить текущую работу или выполнять мероприятия по изменению систему, а развивающему сложно потому что линейный ему не подотчетен и отвечать за выполнение работ он должен только перед вышестоящим.
6. По подчиненности — линейный и развивающий оптимально должны быть на одной ступени иерархии.
Развивающий не может подчиняться линейному — яйца курицу не учат(исключительный случай — линейный хочет сам научится и сам берет к себе такого человека — но это огромнейшая редкость — иногда так поступает генеральный-собственник, когда понимает что ему не хватает знаний).
Линейный может подчиняться развивающему, только если развивающий является генеральным или обособленным руководителем филиала, дивизиона или продукта с персональной ответственностью за результат.
Если интересно, то могу написать статью, где более подробно описать подобную систему и опыт ее внедрения. Только не знаю необходимо ли это на хабре. Все таки это систему управления c IT связано лишь косвенно. Коллеги дайте, пожалуйста, ответ в комментариях — писать статью или нет? Спасибо.
Я, конечно, понимаю, что выскажу непопулярную точку зрения, но диалоги вида
читаются как
в смысле, что даже когда я курсы по программированию вел, мне ученики отвечали на такие вопросы что-то вроде «икс будет равен двум», а тут Лена, менеджер по снабжению, и вдруг такую формулировку выдает.
Видно, что у автора есть интересные мысли но в формате статей «к главному герою приходят что-то спросить, а потом в немом восхищении внимают его Программисткой Мудрости по несколько часов кряду и пусть весь мир подождет» это вызывает только раздражение. Пишите уже просто мысли сборниками подряд, подписывайте «Иван — Гуру Бизнес Программирования» и будет вам счастье и экономия времени.
—Вот напишете вы код: X=2. Что произойдет?
— Не знаю, я не программист…
— Блин, ну это что-то типа математики же…
— Переменной X будет присвоено значение 2?
читаются как
— Вот я вас спрошу — какова орбитальная скорость луны?
— Не знаю, я не астроном…
— Блин, ну это что-то типа типа физики же…
— 1023 км/c при среднем расстоянии между центрами Земли и Луны в 385000 км и средним эксцентриситетом в 0,0549006?
в смысле, что даже когда я курсы по программированию вел, мне ученики отвечали на такие вопросы что-то вроде «икс будет равен двум», а тут Лена, менеджер по снабжению, и вдруг такую формулировку выдает.
Видно, что у автора есть интересные мысли но в формате статей «к главному герою приходят что-то спросить, а потом в немом восхищении внимают его Программисткой Мудрости по несколько часов кряду и пусть весь мир подождет» это вызывает только раздражение. Пишите уже просто мысли сборниками подряд, подписывайте «Иван — Гуру Бизнес Программирования» и будет вам счастье и экономия времени.
Да, мне тоже зацепило, надо поправить. Концепция переменной не так уж сильно проста для понимания, у меня ученики понимают только если через коробочки обьяснять.
А формат отличный, почти как платоновские диалоги.
А формат отличный, почти как платоновские диалоги.
Вот напишете вы код: X=2. Что произойдет?
Смотря где напишу. В некоторых, достаточно популярных языках, это сравнение, в некоторых присваивание, а в некоторых, возможно, эта операция переопределена.
Берете одну книжку, нужную вам. В ней есть список литературы. Указываете эту книжку, и с десяток источников, перечисленных в ней самой. Если не хватает, берете в библиотеке пару книг из этого списка, открываете в конце – там опять список литературы, и тащите еще пару десятков названий. И так, пока не надоест.
Этот метод же не подходит ибо нужно ссылку на источник ставить после фразы которая взята из источника. Ну и в технических вузах список литературы спокойно может состоять из 3-5 пунктов.
— Это странный вопрос, Лена… Как меня может не устраивать система, созданная не мной?… Никаких оценок...
Еще более странный ответ.
Тем не менее «систему» он пытается менять.
Хм… Зачем?
Вообще, если вникнуть то Сергей просто выпендривается на фоне тупящей Лены. Но что он сказал по сути? То, что «системы» можно менять и некоторые этим злоупотребляют? Спасибо, Кэп. Размазать это на 20тыщ знаков — вот, где талант!
В остальном тексте Сергей сам не знает, чего он хочет.
Да, нарциссизм и ЧСВ его толкают «менять систему» походу рассказывая какие все тупые,
но что именно можно улучшить, какие методы проектирования и типовые решения существуют он, очевидно, даже не слышал.
А зачем? Сергей — писатель, а не жалкий читатель.
Жаль, что этот писатель не может даже с терминами опредилиться. То они не нужны — придумаем отсебятину, то потом они необходимы. Причем демагогия на эту тему — пол-интервью.
А вообще, Сергей свою задачу решает: на протяжение всей статьи уверенно и ритмично массажирует свое ЧСВ при этом используя ничтожно малое количество информации. Вот, где эффективность!
На самом деле, если внимательно почитать, Лена не особенно то и тупит: периодически указывает на противоречия в логике Сергея, поддакивает когда его начинает нести и он нервничает. Так ведут себя детские психологи, чтобы и проблему понять и ребенка в истерику не ввести или он в себе не замкнулся по принципу «никто меня не понимает». Или опытные журналисты, когда общаются с очень эксцентричными и зазвездившимися звездами, чтобы хоть какой-то материал для интервью добыть.
Автор, признавайтесь, серия рассказов написана для того чтобы некоторые люди в нашей профессии которые «словили звезду» могли посмотреть на себя со стороны и попытаться исправиться или хотя-бы прокачать софт скилы и научиться свой характер скрывать?
Автор, признавайтесь, серия рассказов написана для того чтобы некоторые люди в нашей профессии которые «словили звезду» могли посмотреть на себя со стороны и попытаться исправиться или хотя-бы прокачать софт скилы и научиться свой характер скрывать?
у этой серии нет цели. Просто пишу, и все.
Плохо когда у программиста нет цели, фигня обычно получается. Иногда сидишь смотришь в код, пытаешься понять «ну вот нафига тут это», а оказывается что просто так, программист развлекался, прочитал про новый паттерн и решил искорежить сложную архитектуру чтобы его применить. Потому что интересный и прикольный. А уж сколько раз я в ответ на вопрос «а почему вы решили использовать именно этот фреймворк/инструмент/базу данных?» слышал «ну хотелось попробовать», и все, это была единственная причина почему люди цепляли крылья с реактивными двигателями к комазу и пытались взлететь. Раз за разом. Даже если ничего не получалось. Упорно и настойчиво. К чужому камазу, который им завезли на техобслуживание и модернизацию, и который уже давно должен колесить по просторам страны перевозя грузы, но стоит в гараже и ожидает когда ему крылья на пропеллер поменяют потому что счас в моде квадракоптеры, а летающий камаз это круто.
Да и с писателями та же фигня. Сидишь иногда, думаешь, а что только что прочитал, что хотел сказать автор, может это я что-то не понял или проскочил, может тут можно действительно что-то полезное почерпнуть — а он просто писал и все, ничего он не собирался говорить, нет у него никакой цели, так троллит читателя когда нужно время убить и скучно, вот и пишет.
Да и с писателями та же фигня. Сидишь иногда, думаешь, а что только что прочитал, что хотел сказать автор, может это я что-то не понял или проскочил, может тут можно действительно что-то полезное почерпнуть — а он просто писал и все, ничего он не собирался говорить, нет у него никакой цели, так троллит читателя когда нужно время убить и скучно, вот и пишет.
Настоящие писатели пишут не для читателей, если что…
«Ну хотелось попробовать» как по мне получше «а я другого инструмента не знаю, только читал на Хабре». Откуда брать знания о том, что лучше подходит для нового проекта, если на предыдущих не пробовал разные альтернативы? Маркетинговым материалам верить?
Незаметных менеджера, программиста, техподдержку (когда система работает и не требует внимания) — увольняют как ненужных бездельников.
ИБД выигрывает, такова уж природа социума. Это неправильно, но так получается.
Характерный пример — чиновники/политики, в массе своей занимающиеся не решением проблем, а их созданием, чтобы оседлать «решение вопроса».
ИБД выигрывает, такова уж природа социума. Это неправильно, но так получается.
Характерный пример — чиновники/политики, в массе своей занимающиеся не решением проблем, а их созданием, чтобы оседлать «решение вопроса».
Я этой хрени наелся еще в аспирантуре, когда на каждый чих надо искать источники, указывать номер страницы и год издательства, просто ради того, чтобы соблюсти некие выдуманные кем-то правила.
А давайте не будем пользоваться чужими наработками и библиотеками, придумывать свои названия и термины для всего, откажемся от стилистических и семантических паттернов в коде, ведь тогда людям будет очень весело и интересно разбираться в куче велосипедов! Зачем соблюдать некие выдуманные кем-то правила?
Гениальным людям выдуманные другими правила, проведенные эксперименты и наработанный опыт — не нужны. Они гениальны и не могут ошибаться, а значит их мнение лучше всех остальных, даже кем-то там проверенным и чем-то подтвержденным. В такой ситуации сноски не нужны. Чужие библиотеки ущербны. Термины, паттерны и прочее нуждаются в изменении и творческой переработке. Как и любой код написанный другими людьми в переписывании с нуля. А система построенная другими по умолчанию ущербна и нуждается в изменении, ведь программист это тот кто меняет! И да, обычные негениальные программисты не должны лезть в код гениального, а значит и разбираться в нем им особо не нужно, так что стандарты действительно не нужны.
Всегда есть передовики – самый авангард, которые придумывают правила высоких абстракций (как Пушкин заапдейтил русский язык, как Кнут/Хаскелл Карри/Бернс-Ли повлияли на IT-мир, ну и так далее), самые или почти самые высокие уровни абстракции, а есть те, которые работают на абстракциях пониже (математик -> физик -> инженер -> эксплуатационщик). Чтобы сделать сайт-визитку, никто в здравом уме не будет писать систему рендеринга шрифтов и операционную систему. Будут использоваться все предыдущие уровни абстакций.
обычные негениальные программисты не должны лезть в код гениального
Если речь идет просто о рокстарах – рядовых, но талантливых исполнителях – тут стандарты вообще не при чем. Они просто делают свою работу хорошо. И да, если этот программист пишет write-only код, то какой он на хрен гениальный? Куда его девать-то вообще, если никто не может работать с его кодом? А как же bus-factor? Команду поддержки нанимать? А не дешевле ли взять вместо этого 3-5 менее гениальных, но командных игроков?
Если речь о тех, кто работает с более высокими абстракциями, то тут как раз ровно наоборот. Все, кто работает на более низких абстракциях ("менее гениальные"), ВСЕГДА и ВСЕ должны основывать на работах "более гениальных". В противном случае нужно будет придумать всю цепочку абстракций вверх, вплоть до математики и процессора, чтобы сделать сайт-визитку. Зачем?
Вот Эйнштейн – он что, свою математику изобрел? Нет, он активно сотрудничал с математиками-передовиками, и именно благодаря тому, что он соблюдал "некие выдуманные кем-то правила", смог создать ОТО.
Они гениальны и не могут ошибаться
Эйнштейн ошибался при касательно некоторых квантовых законов. Он не гениальный? А кто гениальный?
Чужие библиотеки ущербны
...
Термины, паттерны и прочее нуждаются в изменении и творческой переработке
Если что-то можно улучшить, это не значит, что это нельзя использовать. Попахивает юношеским максимализмом или нездоровым идеализмом.
А система построенная другими по умолчанию ущербна
Это ваши личные умолчания, см. пункт выше
Жду выхода книги. Буду дарить всем знакомым директорам и собственникам бизнеса.
Уважаемый автор. Напишите пожалуйста рассказ где Сергея сделали Самым Главным. Он разогнал всех ненужных людей. Повесил на дверь табличку «Гениальный Директор — Генеральный Программист». К нему ходили разные просители, кланялись, дары приносили, на коленях ползали. А он, после не такого уж долгого обьяснения какие они ничтожества и совсем не программисты, решал их проблемы мановением руки, делился своей мудростью и благословлял на хорошую работу. И чтобы они выходили за дверь и восхищенно закатывали глаза «ах какой мудрый человек, пропали бы мы без него», а двухкилометровая очередь у кабинета внимала и просила рассказать что изрек Сергей.
Джва года жду такого рассказа.
А если серьезно, можно поменять Сергею профессию? А то за профессию обидно. Слабовольный, постоянно чешет свое ЧСВ за счет принижения других, мизантроп, разводит философию без конкретики да еще на темы в которых ничего толком не понимает, противоречит сам себе, пытается натянуть автоматизированные процессы на процессы в которых задействованы люди и при этом постоянно жалуется что проблема в людях, они мешают, вот если бы не люди то все бы работало, а с ними процессы не работают потому что они не для людей.
Путь будет например таксидермистом. Их немного, на хабре точно, они сильно не обидятся.
И пусть научиться уже говорить «НЕТ». Вот представьте какой классный рассказ бы получился о лаконичности и принципиальной позиции:
— Сергей! Сергей!
Сергей встрепенулся, оторвался от компьютера и снял наушники. Сбоку стояла Лена, менеджер по снабжению, с какими-то бумагами в руках и вопросительно на него смотрела.
— Чего? – спросил Сергей.
— Интервью.
— Не хочу!
— Сергей, ну пожалуйста, это надо компании.
— Нет!
— Ну ладно, тогда пойду у Миши интервью возьму, пока.
— Пока.
Правда же прекрасно? Результат тот же, текст короче, Леночке не пришлось пол часа обтекать помоями которые щедро вываливал на нее и других Сергей, не пришлось сидеть демонстрируя внимание и при этом чертыхаясь про себя и про себя же повторяя «Держись Лена, ты профессионал, ты справишься, если взялась за дело надо его закончить, пусть и тошнит от пафоса этого Дартаньяна, воспринимай это как тренировку силы воли и умения общаться с людьми с трудными характерами, просто поддакивай, задавай глупые вопросы которые он ждет и давай такие же глупые ответы чтобы его ЧСВ радовалось, и записывай. Держи себя в руках, потом пойдешь в зал и грушу побьешь, а сейчас будь спокойна, участлива и улыбайся, не забывай улыбаться».
Джва года жду такого рассказа.
А если серьезно, можно поменять Сергею профессию? А то за профессию обидно. Слабовольный, постоянно чешет свое ЧСВ за счет принижения других, мизантроп, разводит философию без конкретики да еще на темы в которых ничего толком не понимает, противоречит сам себе, пытается натянуть автоматизированные процессы на процессы в которых задействованы люди и при этом постоянно жалуется что проблема в людях, они мешают, вот если бы не люди то все бы работало, а с ними процессы не работают потому что они не для людей.
Путь будет например таксидермистом. Их немного, на хабре точно, они сильно не обидятся.
И пусть научиться уже говорить «НЕТ». Вот представьте какой классный рассказ бы получился о лаконичности и принципиальной позиции:
— Сергей! Сергей!
Сергей встрепенулся, оторвался от компьютера и снял наушники. Сбоку стояла Лена, менеджер по снабжению, с какими-то бумагами в руках и вопросительно на него смотрела.
— Чего? – спросил Сергей.
— Интервью.
— Не хочу!
— Сергей, ну пожалуйста, это надо компании.
— Нет!
— Ну ладно, тогда пойду у Миши интервью возьму, пока.
— Пока.
Правда же прекрасно? Результат тот же, текст короче, Леночке не пришлось пол часа обтекать помоями которые щедро вываливал на нее и других Сергей, не пришлось сидеть демонстрируя внимание и при этом чертыхаясь про себя и про себя же повторяя «Держись Лена, ты профессионал, ты справишься, если взялась за дело надо его закончить, пусть и тошнит от пафоса этого Дартаньяна, воспринимай это как тренировку силы воли и умения общаться с людьми с трудными характерами, просто поддакивай, задавай глупые вопросы которые он ждет и давай такие же глупые ответы чтобы его ЧСВ радовалось, и записывай. Держи себя в руках, потом пойдешь в зал и грушу побьешь, а сейчас будь спокойна, участлива и улыбайся, не забывай улыбаться».
И почему ваш Сергей постоянно общается с картоном?
Просто прочитайте отдельно реплики собеседника, это же просто соломенного чучело, на котором автор оттачивает навыки убеждения.
Просто прочитайте отдельно реплики собеседника, это же просто соломенного чучело, на котором автор оттачивает навыки убеждения.
//«зануда» mode on
Если написать код X = 2, что-то обязательно произойдет. А переменной X будет присвоено значение 2 тогда, когда написанный код будет «выполнен».
//«зануда» mode off
:)
Если написать код X = 2, что-то обязательно произойдет. А переменной X будет присвоено значение 2 тогда, когда написанный код будет «выполнен».
//«зануда» mode off
:)
А руководители, я прошу прощения, слишком зажрались. Формально – да, изменения – их основная работа.
Не понимаю зачем вводить сущности и что-то переизобретать, если изменениями занимается менеджмент, только из-за того что начальники слишком зажрались? Есть готовая профессия, специальности в университетах. Просто на руководящих должностях должны быть профессионалы, компетентные специально обученные люди.
Суть работы программиста – изменения. Никакая другая профессия из известных мне не стоит так же близко к изменениям, как программист.
Менеджмент всецело в изменениях, потому что нужно принимать постоянно управленческие решения в рамках неопределенности и в постоянно меняющейся окружающей среде.
И Автор, пожалуйста, не путай молодежь.
Программист это человек который решает проблемы/задачи с помощью компьютеров. Чаще всего. Хотя полученные навыки и mindset позволяют в целом строить и модифицировать системы для решения задач и проблем. Даже системы состоящие только из людей и процессов (просто при этом нужно понимать отличия и особенности). Но этим уже не только программисты занимаются, тут можно десятки профессий притянуть. Поэтому оставим вариант «с помощью компьютеров».
И ключевое тут «задачи/проблемы». Программист должен четко понимать для чего он создает или меняет систему. При этом зная что абсолютного понимания нет на любом этапе ни у кого, потому что чаще всего программист работает в экспериментальных областях, каждое решение в чем то уникально, пусть и использует общие принципы. Вот умение построить/модифицировать систему (код, архитектуру, алгоритм) с необходимыми параметрами (гибкость, надежность, стабильность, скорость и пр.) для выполнения определенных задач, в условиях недостаточной информарованности (а часто и компетентности) и определяет уровень программиста, и является его основной задачей и основным умением. Фреймворки, языки, годы опыта — все это сопутствующее и не особо влияет на уровень. И принцип «работает — не трогай» не зря придуман, да он не абсолютен и не универсален, но он лучше «не нравиться — меняй». Более адекватная и запутанная формулировка «прежде чем что-то менять просчитай потенциальные проблемы которые принесут твои изменения, оцени риски, четко определи цели изменений и наметь план изменений, оцени стоит ли вносить эти изменения с учетом всех факторов и только тогда меняй, четко понимая что ты делаешь и зачем. Повторить процесс при изменении внешних данных или когда почувствуешь что узнал систему значительно лучше чем при предыдущем анализе». Ну за исключением когда риски небольшие и можно использовать изменения как эксперимент, с возможностью всегда быстро откатить систему в стабильное состояние.
А у вас программист тупо по определению должен все поменять, ну за исключением того что ему проще пережить чем менять (пример с универом). Ну то есть это человек который приходя на проект сразу кричит — все говно, все надо переделать, и переделывает, как ему нравиться, никого не слушая и не обращая внимания на стандарты, подходы, текущую архитектуру и без всяких целей и задач которые нужно решить этой переделкой, тупо потому что он программист и изменения — это его главная задача! Обычно команда гонит таких «гениев» погаными метлами, потому что вред от него превышает пользу и ломает всем работу.
Программист это человек который решает проблемы/задачи с помощью компьютеров. Чаще всего. Хотя полученные навыки и mindset позволяют в целом строить и модифицировать системы для решения задач и проблем. Даже системы состоящие только из людей и процессов (просто при этом нужно понимать отличия и особенности). Но этим уже не только программисты занимаются, тут можно десятки профессий притянуть. Поэтому оставим вариант «с помощью компьютеров».
И ключевое тут «задачи/проблемы». Программист должен четко понимать для чего он создает или меняет систему. При этом зная что абсолютного понимания нет на любом этапе ни у кого, потому что чаще всего программист работает в экспериментальных областях, каждое решение в чем то уникально, пусть и использует общие принципы. Вот умение построить/модифицировать систему (код, архитектуру, алгоритм) с необходимыми параметрами (гибкость, надежность, стабильность, скорость и пр.) для выполнения определенных задач, в условиях недостаточной информарованности (а часто и компетентности) и определяет уровень программиста, и является его основной задачей и основным умением. Фреймворки, языки, годы опыта — все это сопутствующее и не особо влияет на уровень. И принцип «работает — не трогай» не зря придуман, да он не абсолютен и не универсален, но он лучше «не нравиться — меняй». Более адекватная и запутанная формулировка «прежде чем что-то менять просчитай потенциальные проблемы которые принесут твои изменения, оцени риски, четко определи цели изменений и наметь план изменений, оцени стоит ли вносить эти изменения с учетом всех факторов и только тогда меняй, четко понимая что ты делаешь и зачем. Повторить процесс при изменении внешних данных или когда почувствуешь что узнал систему значительно лучше чем при предыдущем анализе». Ну за исключением когда риски небольшие и можно использовать изменения как эксперимент, с возможностью всегда быстро откатить систему в стабильное состояние.
А у вас программист тупо по определению должен все поменять, ну за исключением того что ему проще пережить чем менять (пример с универом). Ну то есть это человек который приходя на проект сразу кричит — все говно, все надо переделать, и переделывает, как ему нравиться, никого не слушая и не обращая внимания на стандарты, подходы, текущую архитектуру и без всяких целей и задач которые нужно решить этой переделкой, тупо потому что он программист и изменения — это его главная задача! Обычно команда гонит таких «гениев» погаными метлами, потому что вред от него превышает пользу и ломает всем работу.
Интересно в какой главе главный герой столкнётся с "человеческим фактором"?
Это в программе легко обойтись директивой Х=2, а в реальном мире каждому необходимо донести изменение и ещё пару раз проверить как поняли.
Сергей вскользь употребил слово «модерируйте». Я бы к этому слову присмотрелся поближе. Модератор ведь именно тот, кто корректирует процесс, но не завязывает его на себя.
Сергей вскользь употребил слово «модерируйте». Я бы к этому слову присмотрелся поближе. Модератор ведь именно тот, кто корректирует процесс, но не завязывает его на себя.
У модератора нет прав на глобальные изменения, он существует в рамках созданной системы ценностей и ограничений да следует ей, сопровождает. Если система плоха — он максимум может предложить изменения системы тому, кто может её поменять.
Соглашусь с теми комментаторами, кто сказал, что у «героя» рассказа сильно завышено ЧСВ.
И что касается самопроизвольных названий. Мне приходилось читать такие переводы на русский (чаще с английского), по программированию, что очень хотелось настучать по лицу переводчика. Лучше бы он оставил вообще английское слово, пусть и написанное русскими буквами, чем придумывать полную отсебятину. Совершенно реально не понятно было, о чем идет речь. И не говорите «ищи оригинал в тырнете!». Я говорю про те времена, когда тырнета не было или он еще был плохо развит (у нас в стране).
А уж если современный программист за час (за час!!!) не может найти в интернете правильный термин… То это значит, что он не умеет работать с информацией :)
И что касается самопроизвольных названий. Мне приходилось читать такие переводы на русский (чаще с английского), по программированию, что очень хотелось настучать по лицу переводчика. Лучше бы он оставил вообще английское слово, пусть и написанное русскими буквами, чем придумывать полную отсебятину. Совершенно реально не понятно было, о чем идет речь. И не говорите «ищи оригинал в тырнете!». Я говорю про те времена, когда тырнета не было или он еще был плохо развит (у нас в стране).
А уж если современный программист за час (за час!!!) не может найти в интернете правильный термин… То это значит, что он не умеет работать с информацией :)
Спасибо за интересное чтиво. Судя по тому, что я прочитал, то Ваши тексты несут в себе развитие сюжета. На данный момент я прочитал 3 последних ступеней развития(включая эту).
В общем, можно попросить в конце текста указывать ссылки на предыдущий и следующий тексты?
Зачем мне это? Ваши тексты несомненно интересно читать, но в первую очередь мне интересно прочитать сюжетную линию Сергея, а уж потом статьи на другие темы. Времени не всегда хватает на чтение всего, но хочется расставить приоритеты.
В общем, можно попросить в конце текста указывать ссылки на предыдущий и следующий тексты?
Зачем мне это? Ваши тексты несомненно интересно читать, но в первую очередь мне интересно прочитать сюжетную линию Сергея, а уж потом статьи на другие темы. Времени не всегда хватает на чтение всего, но хочется расставить приоритеты.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Корпоративное интервью