Сергей Григорович в одной беседе мне рассказывал как они лазили в Windows Kernel, чтобы дбится перформанса… а тут такие речи — как замедлить! (куда мир катится?)
Серые «артефакты» — это мы не отключали дебажную информацию, чтобы показать как оно в действительности определяет поверхности.
(для реальной работы, сильно не хватает встроенных сенсоров Акселерометра, Гиро и Магнитометра — оно бы тогда в разы быстрее определяло горизонтальные поверхности, как в Project Tango)
еще хотел спросить… как быть с «Авторитетностью»?
в своей компании я долго был девелопером, потом менеджером и внедренцем, чтобы «заработать Доверие и чтобы я смог говорить что-то об Архитектуре»… (тогда еще было мало опыта, но было много Авторитета).
Но пипл тебя слушает, рисуешь им road-map — и все понимают «направление лодки» и готовы креативить в общую сторону — отлично.
Но когда ты приходишь в стороннюю компанию?
Если Архитетора законтрактили по полной стоимости — то местный пипл слушает внимательно и смотрит тебе в рот и ловит каждое слово, и готовы отвечать на вопрос «Зачем» пока не докопаются до "действительной" проблемы (latent pain) и тогда есть бльшой шанс на качественный проект…
Но, обычно, «денег нет», «на всем надо экономить», и даже неплохие Архитекторы-консультанты должны начинать уступать в цене… может даже работать в кредит… и если ты пришел, и стоишь мало — то и ожиданий в коридорах больше, и внимания от местных пиплов тебе по-меньше… и после второго-третего «Зачем» — начиают переходить на личности и всячески сабботировать процесс.
Какие soft-skills и практики помогают:
* правильно выстроить ожидания с Заказчиком до заключения контракта и во время сессии?
* хоть как-то увлечь местных инженеров, чтобы они «расскрылись» и для общей пользы продолжали отвечать на вопрос, докапываясь до реального источника проблем? (ссылки и образцы контрактов — приветсвуются :-) )
Ведь если подумать… СЕО — должен «видеть» куда бежит бизнес компании…
а СІО (Архитектор) — должен дать инструментально-аппаратную поддержку этого видения.
Т.о. «Директор» — выступает «бизнес-архитектором компании»… например, тот же самый, «планируемый бюджет» — это тоже «видение будущего состояния»… и если для выполнения бюджета потребуется утроить количество подписчиков, то задачей ИТ будет «Обеспечить» business continuity роста числа подписчиков.
в любом случае, и один и второй должны сначала дозреть до понимания необходимости «иметь бизнесс-видение» и «иметь Архитектуру».
Правильно, что Архитектор ИТ должен уметь хорошо рисовать (где-то была даже книжечка по базовым основам бизнес-рисунка, скетчинг)
Есть одна из методик «Value Realization Framework», работает в случаях, когда есть доступ к телу самого BigBossa: Ему задаются наводящие вопросы, но главное, что беседа проходит возле флипчарта, и каждый раз BigBoss-у вкладывается в руку фломастер — «рисуй!». Чем больше он будет рисовать — тем больше будет сам расскрывать и понимать и творить и решать (а кто, кроме него знает лучше: куда организация должна двигаться") — в самом лучшем случае, после 40 минут задавания наводящих вопросов и многих рисунков от директора, чем меньше будешь говорить ты, и чем больше монолога будет от него, то в результате услышишь лестное: «вот настоящий специалист, который понимает в моем бизнесе!» (хотя большей частью, ты только поддакивал и кивал головой, но soft-skill — слушать с заинтересованностью! — дверца и откроется :-) )
Прежде чем бросаться отвечать на вопрос «как» (делать, внедрять систему, платформу и т.д.) убедитесь, что ответили на вопрос «зачем».
— я прямо прослезился…
Часто бывает, что BigBoss — нагибает свой отдел ИТ, и те приходят к нам: «ну вы расскажите, как SQL-ферма или облака нам помогут?»
ты начинаешь им задавать «Зачем?», и после пятого (а то и раньше) можно услышать: «ну ты что дИбил? ну ты что сам не понимаешь?? почему ты все время спрашиваешь — ты давай отвечай!» (а ведь он — заказчик… и отвечать надо… а прямого доступа к телу Заказчика нету… и хочешь послать отказать, а коллеги смотрят на тебя с укоризной: «что ж ты брат, денежный проект упускаешь… ИТ-шники заказчика — лохи, им впарить надо, делов-то!»).
я пришел в ИТ, чтобы сделать (создать) что-то хорошее…
(работая в оутсорсинге, посетил много автомобильных заводов https://geektimes.ru/post/259366/, мы делали продукт и я видел как меняется ландшафт (сам менял его) )
Когда цель «достигнута», то просто открываются новые горизонты — с этим нет проблем, всегда вперед — и это «прёт» несказанно!
Создавать ИТ продукты… для (мужчины) программиста — это как дарованная возможность "родить ребенка"… ты видишь как едет машина, а под капотом у нее проводки собраные твоими руками (мозгами) — это есть самая большая награда сама по себе!
но, после 48 — становится трудно (не смертельно, но трудно)…
Про то, что «необходимо откладывать и вкладывать» я понял еще в расцвете карьеры, но как вкладывать правильно — умишко, видать не заточен под это… Сейчас изучаю Unity и учусь публиковать игры под мобильники… Один раз видел в метро человека играющего в мою игру — чуть не кончил на радостях… :-) (FYI)
в свои 32, после 5 лет в ИТ, я понал, что это дорога «в один конец».
Программисты уходят на пенсию, так же как и спортсмены — рано.
Накопления в банке — обесцениваются быстрее чем растут на них проценты (у меня), у знакомых — лопали банки… поэтому сосредоочился на своей собствнной компании… оутсорсинг, коммандировки, много денег, но всеравно, никакой возможности их сохранить… только то, что потратил или пропил — то твое, все остальное — отдашь «кесарю».
в 40 попл на очень крутую наемную работу, с очень высоким заработками, но все равно, не получается их сохранить…
Сейчас в 48, понимаю, что новых фреймворков я уже не потяну, башка еще «варит», но заставить себя работать по 12-16 часов уже немогу… больше 2 часов — и то уже с большим трудом.
Начинаю изучать химию, и список ноотропных лекарств, для улучшения памяти… про «после 50» уже и не волнуюсь, уверен, что надо валить из ИТ.
Не удивлюсь, если итоговая вершина окажется в суде или в анти-коррупционом бюро… как это было при предыдущих президентах, «комитет по борьбе с особо-опасными — крышевал самых опасных» :-)
Басню подтверждаю.
Я о ней знал и кому чинил и настраивал компьютеры — всех сажал на «косынку» именно, чтобы привыть навык в перетягивани, кликах, дабл-кликах и т.п. — работал план отлично!
CD с архивными данными — компановали раз в неделю потом решили XML-ку ZIP-ать и тогда стали возить раз в месяц.
(к слову, разбилась одна машина в Атланте — не сработал Airbag. Подняли данные и доказали, что аирбег был перекручен на СТО, а не был оригинальный с завода… один только этот случай — окупил все внедрение и еще на годы вперед хватило).
Насчет «самосборных заводов» вангую вектор развития в сторону «потребителя», то что он захочет то и сможет себе за кастомизировать… буде-то с помощью гибкого производства или с помощью 3Д печати вопрос вторичный… главное, что для удовлетворения таких потребностей появятся системы (интелектуальные) способные удовлетворить такой спрос на кастомизацию… т.е. плавно ERP — дойдут до состояния AI. вот они-то и будут делать «самособирающиеся заводы».
Отличный вопрос!
я сейчас не дома, мог бы приатачить скриншоты с примерами наших «Work Flow»…
Первую идею родили наши датские колеги, вдохновленные конструктором Lego (может это у них в природе что-то такое? :-) )
Написали ряд «типовых Activities» которые часто встречаются на разных заводах, а потом показали, что простой перекомпоновкой WorkFlow можно добиться ускорения внедрения на конвейер с 12-18 месяцев до 6 месяцев (мой рекорд — 3 месяца от kick-off meeting до первой продукции).
Уточню, только, что этот Work Flow движок был написан практически во время создания первой Workflow Management Coalition/a> для мейнфрема Tandem NonStop Himalaya Server (отдельная сказка… там кернел сервера написан на SQL подобном языке, еще до появления стандарта SQL-82).
средняя инсталяция состояла из одного большого WF (120-250 «тасок») — описывающих реакцию системы на каждый входящих импульс и переводили «наш внутренний Order» — в новый статус. Потом сделали много мелких WorkFlow — которые работали уже непосредственно с конвейерным оборудованием: сканеры, отвертки, мультиметры, и разные лампочки и buzz-еры.
Разница небольшая… что-то типа 17 долл (всего!) за сборку кресла в «хорошую машину» и 11-12 за плохую.
Тут важное, что хотел сказать, что если во время сборки с машиной произошли траблы, любые… ее все равно никто не снимает с конвейера! Просто ставят на нее метку, и на всех остальных участках продолжают на нее прикручивать комплектующие — чтобы не сбился sequence numbers. Точно так же могут запустить на конвейер «фантомную сборку» или «новую модель».
Спасибо Вам огромное!
ушёл читать запоем…
ЗЫ, всомнил, пробегало "Черная книга менеджера" — Стратоплан с этого начинался, насколько я помню…
и сделали небольшой рекламный ролик https://www.youtube.com/watch?v=xU5J_6EtFIU
Серые «артефакты» — это мы не отключали дебажную информацию, чтобы показать как оно в действительности определяет поверхности.
(для реальной работы, сильно не хватает встроенных сенсоров Акселерометра, Гиро и Магнитометра — оно бы тогда в разы быстрее определяло горизонтальные поверхности, как в Project Tango)
в своей компании я долго был девелопером, потом менеджером и внедренцем, чтобы «заработать Доверие и чтобы я смог говорить что-то об Архитектуре»… (тогда еще было мало опыта, но было много Авторитета).
Но пипл тебя слушает, рисуешь им road-map — и все понимают «направление лодки» и готовы креативить в общую сторону — отлично.
Но когда ты приходишь в стороннюю компанию?
Если Архитетора законтрактили по полной стоимости — то местный пипл слушает внимательно и смотрит тебе в рот и ловит каждое слово, и готовы отвечать на вопрос «Зачем» пока не докопаются до "действительной" проблемы (latent pain) и тогда есть бльшой шанс на качественный проект…
Но, обычно, «денег нет», «на всем надо экономить», и даже неплохие Архитекторы-консультанты должны начинать уступать в цене… может даже работать в кредит… и если ты пришел, и стоишь мало — то и ожиданий в коридорах больше, и внимания от местных пиплов тебе по-меньше… и после второго-третего «Зачем» — начиают переходить на личности и всячески сабботировать процесс.
Какие soft-skills и практики помогают:
* правильно выстроить ожидания с Заказчиком до заключения контракта и во время сессии?
* хоть как-то увлечь местных инженеров, чтобы они «расскрылись» и для общей пользы продолжали отвечать на вопрос, докапываясь до реального источника проблем?
(ссылки и образцы контрактов — приветсвуются :-) )
а СІО (Архитектор) — должен дать инструментально-аппаратную поддержку этого видения.
Т.о. «Директор» — выступает «бизнес-архитектором компании»… например, тот же самый, «планируемый бюджет» — это тоже «видение будущего состояния»… и если для выполнения бюджета потребуется утроить количество подписчиков, то задачей ИТ будет «Обеспечить» business continuity роста числа подписчиков.
в любом случае, и один и второй должны сначала дозреть до понимания необходимости «иметь бизнесс-видение» и «иметь Архитектуру».
Есть одна из методик «Value Realization Framework», работает в случаях, когда есть доступ к телу самого BigBossa: Ему задаются наводящие вопросы, но главное, что беседа проходит возле флипчарта, и каждый раз BigBoss-у вкладывается в руку фломастер — «рисуй!». Чем больше он будет рисовать — тем больше будет сам расскрывать и понимать и творить и решать (а кто, кроме него знает лучше: куда организация должна двигаться") — в самом лучшем случае, после 40 минут задавания наводящих вопросов и многих рисунков от директора, чем меньше будешь говорить ты, и чем больше монолога будет от него, то в результате услышишь лестное: «вот настоящий специалист, который понимает в моем бизнесе!» (хотя большей частью, ты только поддакивал и кивал головой, но soft-skill — слушать с заинтересованностью! — дверца и откроется :-) )
— я прямо прослезился…
Часто бывает, что BigBoss — нагибает свой отдел ИТ, и те приходят к нам: «ну вы расскажите, как SQL-ферма или облака нам помогут?»
ты начинаешь им задавать «Зачем?», и после пятого (а то и раньше) можно услышать: «ну ты что дИбил? ну ты что сам не понимаешь?? почему ты все время спрашиваешь — ты давай отвечай!» (а ведь он — заказчик… и отвечать надо… а прямого доступа к телу Заказчика нету… и хочешь
послатьотказать, а коллеги смотрят на тебя с укоризной: «что ж ты брат, денежный проект упускаешь… ИТ-шники заказчика — лохи, им впарить надо, делов-то!»).Спасибо, за добротный текст!
(работая в оутсорсинге, посетил много автомобильных заводов https://geektimes.ru/post/259366/, мы делали продукт и я видел как меняется ландшафт (сам менял его) )
Когда цель «достигнута», то просто открываются новые горизонты — с этим нет проблем, всегда вперед — и это «прёт» несказанно!
Создавать ИТ продукты… для (мужчины) программиста — это как дарованная возможность "родить ребенка"… ты видишь как едет машина, а под капотом у нее проводки собраные твоими руками (мозгами) — это есть самая большая награда сама по себе!
но, после 48 — становится трудно (не смертельно, но трудно)…
Про то, что «необходимо откладывать и вкладывать» я понял еще в расцвете карьеры, но как вкладывать правильно — умишко, видать не заточен под это… Сейчас изучаю Unity и учусь публиковать игры под мобильники… Один раз видел в метро человека играющего в мою игру — чуть не кончил на радостях… :-) (FYI)
но потом купил Дачу для души и все деньги все равно «ушли»… :-)
Программисты уходят на пенсию, так же как и спортсмены — рано.
Накопления в банке — обесцениваются быстрее чем растут на них проценты (у меня), у знакомых — лопали банки… поэтому сосредоочился на своей собствнной компании… оутсорсинг, коммандировки, много денег, но всеравно, никакой возможности их сохранить… только то, что потратил или пропил — то твое, все остальное — отдашь «кесарю».
в 40 попл на очень крутую наемную работу, с очень высоким заработками, но все равно, не получается их сохранить…
Сейчас в 48, понимаю, что новых фреймворков я уже не потяну, башка еще «варит», но заставить себя работать по 12-16 часов уже немогу… больше 2 часов — и то уже с большим трудом.
Начинаю изучать химию, и список ноотропных лекарств, для улучшения памяти… про «после 50» уже и не волнуюсь, уверен, что надо валить из ИТ.
хотел бы добавить, что «коррупционер — никогда не ходит в одиночку», его объязательно кто-то «крышует».
к Вашим симпатичным графикам надо добавить график «связей», что-то типа исследования связей в американском сенате — http://www.forbes.com/sites/ericaswallow/2013/11/17/senate-voting-relationships-data/ (то же еще та, мафиозная структура :-) )
Не удивлюсь, если итоговая вершина окажется в суде или в анти-коррупционом бюро… как это было при предыдущих президентах, «комитет по борьбе с особо-опасными — крышевал самых опасных» :-)
Как раз задумался о том, чтобы сделать «песочные часики» с жидкостями разной плотности, а тут такая полезная статья!
Я о ней знал и кому чинил и настраивал компьютеры — всех сажал на «косынку» именно, чтобы привыть навык в перетягивани, кликах, дабл-кликах и т.п. — работал план отлично!
Видел прототипы, которые ехали по конвейеру — были зачехлены от глаз посторонних.
(к слову, разбилась одна машина в Атланте — не сработал Airbag. Подняли данные и доказали, что аирбег был перекручен на СТО, а не был оригинальный с завода… один только этот случай — окупил все внедрение и еще на годы вперед хватило).
Насчет «самосборных заводов» вангую вектор развития в сторону «потребителя», то что он захочет то и сможет себе за кастомизировать… буде-то с помощью гибкого производства или с помощью 3Д печати вопрос вторичный… главное, что для удовлетворения таких потребностей появятся системы (интелектуальные) способные удовлетворить такой спрос на кастомизацию… т.е. плавно ERP — дойдут до состояния AI. вот они-то и будут делать «самособирающиеся заводы».
я сейчас не дома, мог бы приатачить скриншоты с примерами наших «Work Flow»…
Первую идею родили наши датские колеги, вдохновленные конструктором Lego (может это у них в природе что-то такое? :-) )
Написали ряд «типовых Activities» которые часто встречаются на разных заводах, а потом показали, что простой перекомпоновкой WorkFlow можно добиться ускорения внедрения на конвейер с 12-18 месяцев до 6 месяцев (мой рекорд — 3 месяца от kick-off meeting до первой продукции).
Уточню, только, что этот Work Flow движок был написан практически во время создания первой Workflow Management Coalition/a> для мейнфрема Tandem NonStop Himalaya Server (отдельная сказка… там кернел сервера написан на SQL подобном языке, еще до появления стандарта SQL-82).
средняя инсталяция состояла из одного большого WF (120-250 «тасок») — описывающих реакцию системы на каждый входящих импульс и переводили «наш внутренний Order» — в новый статус. Потом сделали много мелких WorkFlow — которые работали уже непосредственно с конвейерным оборудованием: сканеры, отвертки, мультиметры, и разные лампочки и buzz-еры.
Тут важное, что хотел сказать, что если во время сборки с машиной произошли траблы, любые… ее все равно никто не снимает с конвейера! Просто ставят на нее метку, и на всех остальных участках продолжают на нее прикручивать комплектующие — чтобы не сбился sequence numbers. Точно так же могут запустить на конвейер «фантомную сборку» или «новую модель».