[Тимур]

Ладно, поставим вопрос иначе.

 

Поднимите руки те, кто вообще сталкивался с курсами повышения квалификации. Вообще, какими-нибудь.

 

 

Может все дело в том, что у нас в стране учиться не принято? Все и так от рождения все знают

[kapa]

Ладно, поставим вопрос иначе.

 

Поднимите руки те, кто вообще сталкивался с курсами повышения квалификации. Вообще, какими-нибудь.

 

 

Может все дело в том, что у нас в стране учиться не принято? Все и так от рождения все знают

Я ходил на что-то там от Майкрософта (лет ооочень много назад) и на первый ITIL. Оба не понравились. Но ITIL заинтересовал, и я потом очень много в нём ковырялся сам. Сертификацию, разумеется, не получал. Но если надумаешь кого-то на основы ITIL посылать, то я бы с него сертификацию требовал - прослушать курс мало.

[Milon]

Ладно, поставим вопрос иначе.

 

Поднимите руки те, кто вообще сталкивался с курсами повышения квалификации. Вообще, какими-нибудь.

 

 

Может все дело в том, что у нас в стране учиться не принято? Все и так от рождения все знают

 

и снова я :)

сталкивался. проходил курс «Проектное управление бла-бла-бла» в НОУ «УЦПР» (не реклама). лекторы были не плохие - с опытом, и некоторые даже с умением рассказывать :) но направление немножко специфическое - росатом. лично мне - знаний прибавило. а на учебу я был направлен под давление представителей СРО, т.к. в компании должны быть обученные люди по ряду направлений. и хотя для конторы мое обучение не стоило доп. затрат (почти), через руководство это продвигалось с большим трудом. директорат просто не хотел что бы персонал учился - "мы его обучим, а он уйдет". вот такой менеджмент по русски. из 20-25 сокурсников (не помню уже сколько точно нас было), реально заинтересованных в обучении и приобретении знаний было 3-4. а остальные - спали, читали, бухали :) вот такое обучение по русски :(

сейчас рядом со работают люди, которые учились в сетевой академии Ланит по управлению проектами и ITIL-у. за деньги компании. в результате имеют грамоту, набор ярких брошюр и почти полное отсутствие знаний, т.к. нет подкрепляющей практики и желания развиваться. менеджеры обучение прошли, а до внедрения методик дело так и не дошло: "зачем что-то менять если и так все работает". и главное - всех все устраивает.

[kapa]

из 20-25 сокурсников (не помню уже сколько точно нас было), реально заинтересованных в обучении и приобретении знаний было 3-4. а остальные - спали, читали, бухали :) вот такое обучение по русски :([/size]

сейчас рядом со работают люди, которые учились в сетевой академии Ланит по управлению проектами и ITIL-у. за деньги компании. в результате имеют грамоту, набор ярких брошюр и почти полное отсутствие знаний, т.к. нет подкрепляющей практики и желания развиваться. менеджеры обучение прошли, а до внедрения методик дело так и не дошло: "зачем что-то менять если и так все работает". и главное - всех все устраивает.

 

Вот поэтому я всё время клоню к тому, что нужно искать тех, кто хочет учиться, а не отправлять кого-то на учёбу.

В идеале ещё, чтоб человек за свои готов был учиться. Или впополам предлагать. Тогда будет хоть как-то мотивацию видно.

[Milon]

Но если надумаешь кого-то на основы ITIL посылать, то я бы с него сертификацию требовал - прослушать курс мало.

поддержу. любой экзамен способствует укреплению знаний и повышению мотивации.

[ttttt]

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

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

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

[SergeiK]

Ладно, поставим вопрос иначе.

Поднимите руки те, кто вообще сталкивался с курсами повышения квалификации. Вообще, какими-нибудь.

 

Может все дело в том, что у нас в стране учиться не принято? Все и так от рождения все знают

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

 

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

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

Хотя, опять же, лично я, даже на крайне скучных курсах по охране труда, старался что-то для себя извлечь полезное :).

Да, есть еще другие люди, которые обожают посещать разные курсы, лишь бы не работать :).

[Sergey Gilfanov]

Ладно, поставим вопрос иначе.

Поднимите руки те, кто вообще сталкивался с курсами повышения квалификации. Вообще, какими-нибудь.

Может все дело в том, что у нас в стране учиться не принято? Все и так от рождения все знают

Я на таком сейчас сижу уже два месяца в режиме 8*5, и еще месяца полтора с хвостиком сидеть буду. И да, меня сюда никто не посылал. Сам достаточно целенаправленно вылавливал.

[Milon]

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

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

[Sergey Gilfanov]

и Он примет Правильное решение. а Оракул должен удержать вождя от совершения Большой Ошибки. :)

Терминология тут, конечно.. Это само так получилось, или где(учебниках/лекциях итд) реально использовалось?

[ttttt]

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

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

[Milon]

Терминология тут, конечно.. Это само так получилось, или где(учебниках/лекциях итд) реально использовалось?

как было сказано в одном дурном фильме: "это не мы такие - это жизнь такая"

 

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

похоже - побила Вас реальность российского бизнеса :) меня она тоже расстраивает сильно :(

все люди - разные. есть "ме-е-е-е-е-неджер", а есть "Менеджер". первые - работают в недокорпорациях и фигачат ТЗ и служебные записки, а вторые - помогают руководству разруливать сложные ситуации. я говорю про вторых, а Вы - про первых.

 

 

[SergeiK]

Хотел написать много, по понял, что не потяну, увы. Поэтому напишу коротко.

Если этого будет недостаточно - запишите мне жирный минус :).

 

Сейчас переведу на физический...

Дело в том, что ITIL хорошо задаёт вектора развития, которые очень хорошо ложатся на телеком специфику.

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

 

А теперь кратенько разберём TOGAF.

Вот статеечка http://www.ibm.com/developerworks/ru/library/r-temnenco/index.html

Смотрим рисунок 11

 

Мы видим, что на одном цикле проекта должно родиться 6 (шесть !) документов описывающих план работы.

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

А самое главное-то.

Где вектор-то, который задаёт TOGAF ? Документы рожать ?

Хотя опять же в для крупняка это абсолютно нормально.

Сама картинка относится, по вашей ссылке, к теме связи RUP - TOGAF. Не всем это надо.

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

 

А вот про вектор - вопрос просто отличный. Документы ради документов - штука бессмысленная. Это прямой путь к неработающим архитектурным решениям и еще большему хаосу в ИТ. Такое доводилось видеть :).

 

 

Так зачем же архитектура, и TOGAF, как одна из методологий?

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

Архитектура задает вектор миграции ИТ в компании.

 

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

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

Какие документы создавать? Вы решаете! Вы же для себя, и для компании работает, а не ради документов. Методология вам может подсказать, что вам будет нужно, но вы решаете, что вам действительно нужно.

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

Если вам надо сконцентрироваться на ПО, а инфраструктура работает, и работает нормально - оставьте часть архитектуры инфраструктуры, вернетесь к ней, когда будет нужно.

И т.д..

 

Или вот ещё хорошая картинка - я бы её назвал мир во всём мире.

 

 

Ну да, для крупной IT компании наличие службы архитектора - необходимость.

Но Тимуру-то не нужно 8 архитекторов, причём за каждым из них нужно понимать стоит подразделение.

Вот, ниже, написал другой участник дискуссии:

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

Разве не об одном и том же человеке идет речь? :).

В небольшом объеме не нужно 8 архитекторов, но все равно, кто-то должен понимать, как же работает всё IT вместе, при этом уметь говорить с "бизнесом" на их языке, и понимать требования финансистов к бюджетной дисциплине.

 

 

Поэтому TOGAF - это инструмент расшивки и обхода противоречий, чтоб избежать лишних рестартов циклов проектов из-за ошибок,

а ITIL - метод работы.

Поэтому ITIL применим на средних масштабах, да даже и на совсем малых, если много frontend работы,

а TOGAF ну вот как-то очень слабо.

 

Кстати TOGAF крайне похож на службы Главных Конструкторов советских КБ и НИИ.

Они функционировали похожим образом.

В целом - согласен и с формулировкой, что архитектура (не только TOGAF) - инструмент расшивки противоречий в ИТ.

Я бы даже сказал, что отличная формулировка, мне очень понравилась!

 

Вопрос: есть ли противоречия в ИТ, и требуют ли они расшивки, в компании масштаба Тимура?

[Kirya]

Ладно, поставим вопрос иначе.

 

Поднимите руки те, кто вообще сталкивался с курсами повышения квалификации. Вообще, какими-нибудь.

 

Может все дело в том, что у нас в стране учиться не принято? Все и так от рождения все знают

Получение второго высшего экономического, пойдёт ?

Ну, если пойдёт, меня запишите.

 

Развлечения для получения CCIE и MSCE конечно можно тоже записать,

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

It's not exactly rocket science.

(корректного перевода на русский этого выражения дать не могу)

[kapa]

Получение второго высшего экономического, пойдёт ?

Ну, если пойдёт, меня запишите.

И меня! И тоже не понравилось! :)

На курсере сейчас больше полезного.

[Kirya]

Ну я только по одному пункту пройдусь.

В остальном подпишусь под каждым словом.

 

Так зачем же архитектура, и TOGAF, как одна из методологий?

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

Архитектура задает вектор миграции ИТ в компании.

Правильная архитектура не задаёт вектор развития.

Архитектура даёт устойчивость.

Противоположные задачи....

Поэтому роль архитектора в небольших масштабах тут же схлопывается

в методологию - всё задублировалили и сидим на попе ровно.

Нет более стабильного места, чем кладбище.

:)

[Sergey Gilfanov]

Правильная архитектура не задаёт вектор развития.

Архитектура даёт устойчивость.

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

Но это если ее для этого делали, а не для устойчивости AKA 'ничего не меняется даже если дата-центр снесешь'.

[Kirya]

Получение второго высшего экономического, пойдёт ?

Ну, если пойдёт, меня запишите.

И меня! И тоже не понравилось! :)

На курсере сейчас больше полезного.

Ну у меня всё-таки наверное 50/50.

Меня год накачивали на фин. аналитика.

И мне пришлось же год потратить на доказывание,

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

В итоге доп. нагрузки без какого-то полезного результата...

[Kirya]

Правильная архитектура не задаёт вектор развития.

Архитектура даёт устойчивость.

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

Но это если ее для этого делали, а не для устойчивости AKA 'ничего не меняется даже если дата-центр снесешь'.

Сергей, Вы понимаете, что сейчас выдали оксюморон ?

 

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

Это тоже отличный пример устойчивости.

 

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

Да ну нафиг эти изменения. Лучше ещё контур задублируем и вообще одгородимся от внешнего мира....

 

Работает, не трожь. ©Эксплуатационное

Знакомо ?

Изменено 7 июня, 2016 пользователем Kirya

[Sergey Gilfanov]

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

Но это если ее для этого делали, а не для устойчивости AKA 'ничего не меняется даже если дата-центр снесешь'.

Сергей, Вы понимаете, что сейчас выдали оксюморон ?

 

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

Это тоже отличный пример устойчивости.

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

[karpa13a]

Поднимите руки те, кто вообще сталкивался с курсами повышения квалификации. Вообще, какими-нибудь.

психолог(как работать с командой)+целимся на результат+всякие кулуары While Rider

командообразование в качестве жертвы, а потом и орга)

преподавание в универе, участие в комиссии на госах. как раз сейчас начались.

 

на самом деле все эти мба и прочие итилы - в чистом виде в анархии/бардаке не запустить (ты меня знаешь? я тебя знаю - погнали). ну если нет желания всрать 50%+ персонала и не только линейного)

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

про затраты не забывать. (PMBOK в плане ресурсов может помочь)

и начать спрашивать за результативность. всегда. по результату спустя 1-2-3-6 месяцев будет видна формальная результативность. давать оценку этой результативности по вкусу: бонусы или на мороз(задачи с этой стороны брать в третью очередь или и вовсе сократить лимиты. пусть больше тратит времени на подумать). но тоже обязательно.

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

 

теперь про людей, в основном коммерсы это любят но и бывают другие граждане:

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

такого не допускать. проверяется просто - прокручивается в голове сценарий "а вот что будет с конторой если этот человек исчезнет", практическое наблюдение - отпуска. если ничего не меняется - значит всё ок.

 

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

работать по ТЗ. если ТЗ в пути меняется - на мороз заказчика или отдельными задачами на доработку. что бы было видно снаружи.

принимать работу по ТЗ, программисты - могут пропускать пункты из задачи (не лечится).

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

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

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

 

если эту минималку запустить - то уже будет проще к пониманию и принятию решений. а дальше уже каждую часть расширять и углублять по необходимости.

[NN----NN]

на самом деле все эти мба и прочие итилы - в чистом виде в анархии/бардаке не запустить (ты меня знаешь? я тебя знаю - погнали). ну если нет желания всрать 50%+ персонала и не только линейного)

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

про затраты не забывать.

....

 

(остальное тоже верно, "откусил" для краткости)

Изменения, жёсткость/порядок и системный подход - одобрямс. Начал бы с грубой оценки разных хотелок по критерию "прогнозные доходы vs. возможные затраты".

Изменено 7 июня, 2016 пользователем NN----NN

[kapa]

работать по ТЗ. если ТЗ в пути меняется - на мороз заказчика или отдельными задачами на доработку. что бы было видно снаружи.

принимать работу по ТЗ, программисты - могут пропускать пункты из задачи (не лечится).

 

Вообще не аджайл стайл. :)

Я так понимаю, что разработка внутренняя. Множество вещей разрабатываются в первый и последний раз. В такой ситуации можно и НУЖНО менять ТЗ. Мало того - пытаться сразу разработать железобетонное ТЗ вредно.

[MATPOC]

It's not exactly rocket science.

(корректного перевода на русский этого выражения дать не могу)

«Тоже мне - бином Ньютона…» (с) АБС, Сталкер Тарковского.

[SergeiK]

Ну я только по одному пункту пройдусь.

В остальном подпишусь под каждым словом.

Спасибо на добром слове.

 

Так зачем же архитектура, и TOGAF, как одна из методологий?

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

Архитектура задает вектор миграции ИТ в компании.

Правильная архитектура не задаёт вектор развития.

Архитектура даёт устойчивость.

Противоположные задачи....

Поэтому роль архитектора в небольших масштабах тут же схлопывается

в методологию - всё задублировалили и сидим на попе ровно.

Нет более стабильного места, чем кладбище.

:)

А тут еще раз, с вашего позволения, возражу.

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

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

 

Но его-то место другое.

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

Если бизнес стабилен, и не меняется, а цена простоя - миллиард - стабильность и консервация наше всё! Хотя и тут разумность желательна :).

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

Если потребности бизнеса меняются, архитектура должна меняться.

 

Я сам чувствую некоторый диссонанс в звучании слова архитектура, которая в моем личном восприятии означает что-то недвижимое и монументальное, на века!. Оно плохо соотносится с понятием архитектуры, о котором я пишу :).

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

Так же и архитектура предприятия.