Занимаюсь по работе активно технологическим развитием заказчиков из финансового сектора и в частности страховых компаний. Даже написал статью в журнал "Современные страховые технологии" про основные тренды в мировом ИТ и их отображении на страхование. Собственно сама статья тут, правда доступ к ней платный ... http://www.consult-cct.ru/strahovanie/It-adaptaciya-trendy-v-razvitii-informacionnyh-tehnologij.html. Уточню в редакции, можно ли будет ее публиковать у себя в блоге.
пятница, 27 декабря 2013 г.
воскресенье, 10 марта 2013 г.
Методология, свод знаний, процессный фреймворк, нотация, стандарт ... как тут не запутаться?
Почитал обсуждение на UML2.RU, по его мотивам решил немного порассуждать по этой теме. Собственно вопрос в том, что иногда возникает в головах путаница что есть что и как эти понятия с собой соотносятся. По-хорошему для того, чтобы бы не путаться следует создавать глоссарий (или использовать готовые, англоязычные, только иногда имеет смысл делать их value added перевод :-) ).
Если подходить формально, то МЕТОДОЛОГИЯ - это некий мета уровень, т.е. учение о конкретных методах познания объекта познания (по данным Википедии, другие источники не смотрел). Но в практике ИТ как правило "так не заморачивваются" и под методологией часто понимают, что-то близкое к определению, которое дает глоссарий BABOK (A set of processes, rules, templates, and working methods that prescribe how business analysis, solution development and implementation is performed in a particular context). В этом определении смело можно заменить фразу "business analysis, solution development and implementation" на что-то что более релевантное (вот словечко "подцепил", работая в MS ;-)) к конкретной области и оно станет универсально (в этом определении говорится скорее про методологию создания "РЕШЕНИЯ вообще", контекстом которого в нашем случае может быть и заказное ПО, т.н. интеграционное решение иди Enterprise Architecture - как вполне себе решение). Это определение, на мой взгляд, очень даже жизнеспособное. Примерами методологий вполне можно считать тот же SADT, и более специфично - в области создания "преимущественно программных решений" - условно RUP, ну и Agile (обобщенно). Тут конечно сразу же возникает термин "процессный фреймворк", к которому скорее можно отнести тот же RUP. И это название даже более точно отражает его суть, чем термин "методология". Думаю, что в данном конкретном случае принимая за основу определение от BABOK, вполне можно называть тот же RUP - методологией. В любом случае, исходя из вышесказанного, можно считать, что методология нас направляет на конечный результат, и говорит каким образом его можно достичь. При этом в большинстве случаев степень детализации описания методологии может различаться от МЕТОДОЛОГИИ к МЕТОДОЛОГИИ. А конкретный набор шагов, состав результатов и их содержимое могут быть подвержены существенной "кастомизации" при работе в конкретных условиях, на конкретном проекте и это отдельная работа.
Говоря о СВОДЕ ЗНАНИЙ, примерами которого являются тот же BABOK, SWEBOK, PMBOK, ... следует понимать, что свод знаний как правило менее конкретен (специфичен). Он выполняет роль сбора в одном месте всего, что мы знаем об определенной области деятельности. Вполне может быть, что на основании свода знаний может быть построена МЕТОДОЛОГИЯ. Другой вопрос, что зачастую методологии и своды знаний имеют множество "пересечений", но это просто нужно "принимать как есть", т.к. "nobody care about it".
Теперь мы добрались до НОТАЦИЙ. Если подходить неформально, то под нотацией обычно понимается некий язык (чаще - графический), или структура, позволяющая унифицированным образом описать статическую и/или динамическую модель системы или ее части (в качестве системы может выступать и целая предметная область). Графическими нотациями является например семейство языков IDEF, или тот же UML, или BPMN. Нотации часто являются составной частью МЕТОДОЛОГИЙ, или МЕТОДОЛОГИИ используют для описания тот или иной язык (нотацию). Например, RUP использует UML, SADT - устойчиво ассоциирован с IDEF и т.п.
Говоря о вариантах использования (use cases) - следует четко определять контекст - о чем мы говорим, т.е. мы говорим о части языка UML или же о текстовых описаниях. Во избежании путаницы, далее речь пойдет о вариантах использования как о текстовых структурированных описаниях. Тот же К. Вигерс отводит место вариантам использования, как некой нотации, которая позволяет описывать пользовательские требования. Следует отметить, что пользовательские требования могут быть описаны разными способами, одним из которых (и достаточно эффективным в определенных ситуациях) являются варианты использования. В этом случае вполне можно согласиться с точкой зрения Вигерса о юзкейсах, как фактически о нотации.
Рассматривая СТАНДАРТЫ - тут все хуже ... :-). Стандартом в принципе может являться все из выше перечисленного. Другой вопрос СТАНДАРТОМ какого уровня - международным, государственным, отраслевым, корпоративным ... Говоря о требованиях и стандартизации, можно сказать, что в большинстве случаев имеются стандарты на содержание ДОКУМЕНТАЦИИ, которые содержат в себе требования. Тот же IEEE 830 или ГОСТ 34.602. Иногда даются рекомендации, как следует формулировать требования и как их следует разделять в документах.
Если подходить формально, то МЕТОДОЛОГИЯ - это некий мета уровень, т.е. учение о конкретных методах познания объекта познания (по данным Википедии, другие источники не смотрел). Но в практике ИТ как правило "так не заморачивваются" и под методологией часто понимают, что-то близкое к определению, которое дает глоссарий BABOK (A set of processes, rules, templates, and working methods that prescribe how business analysis, solution development and implementation is performed in a particular context). В этом определении смело можно заменить фразу "business analysis, solution development and implementation" на что-то что более релевантное (вот словечко "подцепил", работая в MS ;-)) к конкретной области и оно станет универсально (в этом определении говорится скорее про методологию создания "РЕШЕНИЯ вообще", контекстом которого в нашем случае может быть и заказное ПО, т.н. интеграционное решение иди Enterprise Architecture - как вполне себе решение). Это определение, на мой взгляд, очень даже жизнеспособное. Примерами методологий вполне можно считать тот же SADT, и более специфично - в области создания "преимущественно программных решений" - условно RUP, ну и Agile (обобщенно). Тут конечно сразу же возникает термин "процессный фреймворк", к которому скорее можно отнести тот же RUP. И это название даже более точно отражает его суть, чем термин "методология". Думаю, что в данном конкретном случае принимая за основу определение от BABOK, вполне можно называть тот же RUP - методологией. В любом случае, исходя из вышесказанного, можно считать, что методология нас направляет на конечный результат, и говорит каким образом его можно достичь. При этом в большинстве случаев степень детализации описания методологии может различаться от МЕТОДОЛОГИИ к МЕТОДОЛОГИИ. А конкретный набор шагов, состав результатов и их содержимое могут быть подвержены существенной "кастомизации" при работе в конкретных условиях, на конкретном проекте и это отдельная работа.
Говоря о СВОДЕ ЗНАНИЙ, примерами которого являются тот же BABOK, SWEBOK, PMBOK, ... следует понимать, что свод знаний как правило менее конкретен (специфичен). Он выполняет роль сбора в одном месте всего, что мы знаем об определенной области деятельности. Вполне может быть, что на основании свода знаний может быть построена МЕТОДОЛОГИЯ. Другой вопрос, что зачастую методологии и своды знаний имеют множество "пересечений", но это просто нужно "принимать как есть", т.к. "nobody care about it".
Теперь мы добрались до НОТАЦИЙ. Если подходить неформально, то под нотацией обычно понимается некий язык (чаще - графический), или структура, позволяющая унифицированным образом описать статическую и/или динамическую модель системы или ее части (в качестве системы может выступать и целая предметная область). Графическими нотациями является например семейство языков IDEF, или тот же UML, или BPMN. Нотации часто являются составной частью МЕТОДОЛОГИЙ, или МЕТОДОЛОГИИ используют для описания тот или иной язык (нотацию). Например, RUP использует UML, SADT - устойчиво ассоциирован с IDEF и т.п.
Говоря о вариантах использования (use cases) - следует четко определять контекст - о чем мы говорим, т.е. мы говорим о части языка UML или же о текстовых описаниях. Во избежании путаницы, далее речь пойдет о вариантах использования как о текстовых структурированных описаниях. Тот же К. Вигерс отводит место вариантам использования, как некой нотации, которая позволяет описывать пользовательские требования. Следует отметить, что пользовательские требования могут быть описаны разными способами, одним из которых (и достаточно эффективным в определенных ситуациях) являются варианты использования. В этом случае вполне можно согласиться с точкой зрения Вигерса о юзкейсах, как фактически о нотации.
Рассматривая СТАНДАРТЫ - тут все хуже ... :-). Стандартом в принципе может являться все из выше перечисленного. Другой вопрос СТАНДАРТОМ какого уровня - международным, государственным, отраслевым, корпоративным ... Говоря о требованиях и стандартизации, можно сказать, что в большинстве случаев имеются стандарты на содержание ДОКУМЕНТАЦИИ, которые содержат в себе требования. Тот же IEEE 830 или ГОСТ 34.602. Иногда даются рекомендации, как следует формулировать требования и как их следует разделять в документах.
воскресенье, 30 сентября 2012 г.
Анатолий Карачинский и Цукерберг ...
Таки да, бросилась в глаза заметка на CNews http://www.cnews.ru/top/2012/09/28/glava_ibs_potryasen_chto_cukerbergu_ne_stydno_vstrechatsya_s_medvedevym_504718 про возмущение основателя IBS предложением Facebook по "эвакуации талантов". Только мне не вполне понятны мотивы для такого возмущения ... анализируя возможные причины, можно предположить следующее:
1. А. Карачинскому "за державу обидно", т.е. имеем ментальные причины
2. У возмущения есть материальные причины ...
Зная специфику работы наших системных интеграторов особенно с госсектором, в духовность и прочия как-то не очень верится. А вот сожаление, что кто-то соблазнится на более комфортные условия жизни из тех, на труде которых компания сейчас зарабатывает - это вполне понятный повод для возмущения.
Тут можно много говорить о том, что и в России талантливые разработчики могут хорошо зарабатывать, но жить все-равно комфортнее там - и инфраструктура лучше и климат теплее и медицина лучше, да и продукты питания можно выбирать ОРГАНИК и даже при продажи рыбы в магазине понятно ее происхождение - дикая или выращенная на ферме... Так что тут можно не обсуждать тему....
Еще один аргумент возмущающихся - это полученное якобы за счет государства образование, которое талантливый выпускник вуза не отработал. Тут вот хотелось бы разораться ... Коль скоро ВУЗ был государственный, значит существовал в т.ч. на налоги родителей выпускника. Тогда получается, что за образование ребенка родители уже заплатили своими налогами? Тогда какие претензии?
При текущем раскладе, когда национальной идеей элиты является "делать деньги в России для комфортной жизни за границей" пытаться удерживать таланты в стране призывами к морали, чувству долга - верх цинизма. Все подобные разговоры следует рассматривать не более чем желание сохранить ресурсы, на которых можно, совершенно верно - "делать деньги в России для комфортной жизни за границей" ...
1. А. Карачинскому "за державу обидно", т.е. имеем ментальные причины
2. У возмущения есть материальные причины ...
Зная специфику работы наших системных интеграторов особенно с госсектором, в духовность и прочия как-то не очень верится. А вот сожаление, что кто-то соблазнится на более комфортные условия жизни из тех, на труде которых компания сейчас зарабатывает - это вполне понятный повод для возмущения.
Тут можно много говорить о том, что и в России талантливые разработчики могут хорошо зарабатывать, но жить все-равно комфортнее там - и инфраструктура лучше и климат теплее и медицина лучше, да и продукты питания можно выбирать ОРГАНИК и даже при продажи рыбы в магазине понятно ее происхождение - дикая или выращенная на ферме... Так что тут можно не обсуждать тему....
Еще один аргумент возмущающихся - это полученное якобы за счет государства образование, которое талантливый выпускник вуза не отработал. Тут вот хотелось бы разораться ... Коль скоро ВУЗ был государственный, значит существовал в т.ч. на налоги родителей выпускника. Тогда получается, что за образование ребенка родители уже заплатили своими налогами? Тогда какие претензии?
При текущем раскладе, когда национальной идеей элиты является "делать деньги в России для комфортной жизни за границей" пытаться удерживать таланты в стране призывами к морали, чувству долга - верх цинизма. Все подобные разговоры следует рассматривать не более чем желание сохранить ресурсы, на которых можно, совершенно верно - "делать деньги в России для комфортной жизни за границей" ...
пятница, 6 июля 2012 г.
Не попал на ЛАФ 2012 :-(
Только вернулся из отпуска ... к сожалению не смог попасть на ЛАФ 2012 в Иваново. Надеюсь на следующий год получиться!
четверг, 23 февраля 2012 г.
О дискуссии по поводу статьи А. Новичкова и Ко на uml2.ru/
С сожалением был вынужден ввязаться в дискуссию которая развернулась на форуме uml2.ru http://www.uml2.ru/forum/index.php?topic=4634.0 по поводу статьи А. Новичкова и Ко об ИТ и психологии. Для меня было интересным не столько сама публикация, сколько развернувшаяся дискуссия (хотя дискуссией ЭТО назвать достаточно сложно). Лишний раз убеждаюсь в справедливости утверждения, что там где одни видят проблемы - другие видят возможности. Тема психологии и отношений в ИТ командах на текущий момент в России особо не раскручена - не упакована как следует и не подана как товар. Я еще в свою бытность фрилансером на полном серьезе обдумывал при комплексном обучении аналитиков давать им определенные навыки психологии общения (с заказчиком и с коллегами-разработчиками). Даже помнится с Александром Байкиным мы обсуждали эту тему с одной дамой, которая делала тренинги по "психологии в бизнесе". И вот эта тема получила продолжение в том, чем занимается Александр Новичков. В то же время, один из участников дискуссии, занимающийся обучением аналитиков, в форме, далекой от цивилизованной дискуссии банально охаивал данную публикацию А. Новичкова. Я честно порекомендовал коллеге вместо "наезда" использовать эту тему и совместно с автором "доточить", упаковать и довести до состояния товара - давая дополнительные знания аналитикам. Однако коллега столь сильно увлекся самовыражением, что перестал воспринимать здравые рекомендации по расширению собственного же бизнеса - пытаясь не оставить камня на камне от публикации и автора лично. Эмоции вредят бизнесу, так же как и позиция видения проблем, там где можно найти возможности .... Хотя не удивлюсь, если через некоторое время в курсе коллеги появится соответствующий раздел о психологии общения и т.п. .... .
Изменения в карьере .... не опять, а снова :-)
Что-то я забросил свой блог совсем. Признаться времени с середины прошлого года не было вообще .... проекты сплошняком (особенно запомнилась работа по проекту НПРОД ;-))). А потом смена работы ... да, я перешел в ноябре 2011 года в компанию Microsoft, на позицию Account Technology Strategist (честно говоря я сам не понимаю как это перевести адекватно на русский, хотя у меня есть несколько идей ... - может у кого еще есть идеи ?). Теперь занимаюсь, скажем так, технологическим развитием конкретных заказчиков (за которых отвечаю я в паре с Account Manager) из банковского сектора и страховых компаний ....
Вообще идея иметь выделенного человека в конкретных заказчиках, который бы помогал этим заказчикам с применением технологий вендора (на стратегическом уровне, а не на уровне техподдержки) и находил новые opportunities сама по себе очень правильная. По сути, это реализация стратегии win-win в "игре" м/у вендорами и заказчиками.
Вообще идея иметь выделенного человека в конкретных заказчиках, который бы помогал этим заказчикам с применением технологий вендора (на стратегическом уровне, а не на уровне техподдержки) и находил новые opportunities сама по себе очень правильная. По сути, это реализация стратегии win-win в "игре" м/у вендорами и заказчиками.
вторник, 3 мая 2011 г.
Полезные ссылки на бронирование отелей, прокат автомобилей, авиабилеты и т.д.
Все тут: http://smarttravel.livejournal.com/ ... лично я воспользовался советами ... :-)
Подписаться на:
Сообщения (Atom)