Как стать автором
Обновить
19
-7.3
Алексей Радзишевский @ARadzishevskiy

CEO, Системный аналитик, PM, Преподаватель ИТ

Что опять не так с Джунами в ИТ?

Время на прочтение 5 мин
Количество просмотров 52K

В последнее время на рынке ИТ специалистов все очевиднее обнажается проблема отторжения Джуниоров. То есть Мидл специалисты в дефиците, они всем нужны, их все хотят, а вот Джуниор не требуется «ни под каким соусом». А ведь еще не так давно зеленых выпускников ВУЗов богатые ИТ‑функционеры скупали прямо на выходе из образовательного заведения, причем за приличные деньги, чем изрядно тревожили, остальной сегмент рынка.

И вот все изменилось. Почему же так произошло и каким образом этому противостоять?

Для начала следует договориться, как именно надлежит идентифицировать специалиста, которого именуют — Джуниором. В широких массах в эту категорию включают всех подряд, от выпускника ВУЗа, до молодых сотрудников, отработавших иногда и 3 и даже 5 лет. Согласитесь, что охват возможностей и навыков в таком диапазоне разворачивается уж в слишком широко, а потому сопряжен с рисками нанять непригодного для производства сотрудника (по крайней мере на обозримое будущее).

Для того же чтобы избежать путаницы и разночтений, этот сегмент следует нарезать на отдельные части.

То, что выпускают наши ВУЗы в большинстве случаев, можно назвать «Уверенный пользователь» и не больше того. Даже если перед нами чемпион олимпиад, реальное ИТ‑производство требует гораздо более глубоких и разнообразных навыков и умений, чем он смог приобрести, участвуя в тепличных соревнованиях ВУЗа. Еще хуже дела обстоят с выпускниками дистанционных ИТ‑школ, проходящих обучение без отрыва от основного производства (особенно если оно не ИТ). Так возникает первая преграда на пути вчерашнего выпускника в ИТ‑профессию — слишком далеки они от реалий производства.

Читать далее
Всего голосов 55: ↑24 и ↓31 -7
Комментарии 210

Краткий обзор стажировки в ИТ фирме или рефакторинг истории о Карабасе Барабасе

Время на прочтение 7 мин
Количество просмотров 1.2K

Немного о предпосылках исследования. Мы ИТ-компания, которая на базе своего офиса занимается проблемами “переработки” студентов ИТ-специальностей в ИТ-специалистов. За несколько лет мы весьма преуспели на этом поприще и трансформировали отдельные процессы в бизнес-конвейер. Загружается он в местном федеральном ВУЗе, в котором мы, бок об бок с тамошними педагогами, преподаем несколько ключевых дисциплин, смягчая сухую академичность предметов - нашим повседневным опытом. Дальше заботливо отбирая лучших студентов, отправляем их на стажировку в стены своей фирмы, где они, как и положено обучающимся, методично преодолевают создаваемые нами трудности.

Закончиться этап стажировки может лишь в результате успешного прохождения нашего внутреннего собеседования на профпригодность, в котором в качестве интервьюеров участвуют все желающие открыть соискателю глаза на уровень его некомпетентности. Если энное по счету собеседование практикант все же смог не завалить, вуаля - компания рождает нового сотрудника! Молодые, голодные до настоящей работы кадры еще немного “томятся” на скамейке запасных, во внутреннем проекте, ожидая запроса от наших партнеров на поставку недостающих им специалистов. Как только такой интерес проявлен, мы бережно упаковываем молодых сотрудников в команды и предоставляем на аутстаффинг. После всего того, что они превозмогли до сего момента, за благополучность прохождения их собеседования у заказчика, мы можем уже не волноваться.

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

Читать далее
Всего голосов 7: ↑4 и ↓3 +1
Комментарии 8

Платформа для организации производства Информационных систем. Часть 2

Уровень сложности Средний
Время на прочтение 7 мин
Количество просмотров 1.2K

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

Читать далее
Всего голосов 2: ↑1 и ↓1 0
Комментарии 5

Платформа для организации производства Информационных систем. Часть 1

Уровень сложности Средний
Время на прочтение 7 мин
Количество просмотров 1.6K

I Вступление

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

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

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

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

Но эта тема получила новый импульс после ухода с рынка РФ части игроков.

Обсуждению вопросов организации производства ИТ-продуктов и посвящена данная статья.

Читать далее
Всего голосов 5: ↑3 и ↓2 +1
Комментарии 5

Трансформация ИТ образования. Мы наш, мы новый мир построим

Время на прочтение 5 мин
Количество просмотров 2.9K

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

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

Область проблем

Касаемо массового доп. Образования. В настоящее время, чаще всего на курсы набирается разношерстный народ, вовлеченный обещаниями: «Обучение «с нуля», «зарплата от 100 тыс.  в месяц». А дальше, втянутых в эту авантюру (в хорошем смысле слова), в очень сжатые сроки «бомбят» теорией с элементами самообучения по темам. Практические занятия обычно проводятся на столько бегло, что только отчасти дают представление о том, как выхваченные ранее обрывки теории соотносятся с практикой. Смотреть на самостоятельные работы, даже лучших, без сожаления невмоготу, а остальные и вовсе их не делают. Такое состояние дел в общем то приемлемо на ранних стадиях изучения темы, но страшно то, что других стадий уже и не будет, обучающиеся перескакивают дальше к следующим предметам, а организаторы курсов считают это уместным. «Участники обучения» без обиняков честно сознаются, что они просто-напросто не успевают готовить задания, да и количество их в группах таково, что преподаватели не могут физически охватить всех своим вниманием. Ведь разбор заданий, выполненных учащимся, это отдельная кропотливая работа наставника, который должен не просто указать на ошибки, а натолкнуть на мысль, что не так выполнено, почему не так и, как выполнить правильно. Когда в группе 80 человек и 1,5 часа на практическое занятие, извините это не практика, а профанация. Нет, конечно, результаты в большинстве случаев есть, люди, прошедшие через горнило таких курсов, получают определенное представление о том, как примерно могут создаваться ИТ-продукты, но для участия в их создании, они увы пока непригодны.

Читать далее
Всего голосов 4: ↑1 и ↓3 -2
Комментарии 9

Анализ практики взращивания студентов для успешного развития ИТ бизнеса

Время на прочтение 8 мин
Количество просмотров 2.2K

Борьба с дефицитом специалистов в ИТ отрасли так или иначе вынуждает ИТ функционеров рассматривать новые варианты возможностей утолить ресурсный голод предприятия.

Поскольку на рынке существует явная напряженка с ИТ специалистами, то очевидно самым доступным способом приобрести их вне рынка, является перекупка у конкурентов или даже партнеров. Но в этой схеме в последнее время образовались существенные ограничения – цена вопроса и наличие возможности заплатить эту цену. Если у фирмы есть хоть легкое финансовое недомогание, то вступать в гонку наращивания зарплат – явно бесперспективно.

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

И что же остается для большинства заурядных предприятий в ИТ отрасли?

Собирать на рынке тех специалистов, чей профиль так или иначе отличается от предпочтительного профиля топовых игроков ИТ рынка.

Для анализа этого сегмента, давайте разберем, в чем могут выражаться отклонения характеристик подобного специалиста?

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

Рассматривая такого рода соискателя, в обоих случаях важно усмотреть реальность перспектив, исправить положение дел в проблемных местах, мешающих на полную катушку использовать производственную единицу сотрудника. То есть оценить, готов ли и способен ли он повышать свою квалификацию и коммуникативность. Статистика показывает, что с возрастом желание и готовность учиться значительно снижается. Интересы зрелого сотрудника чаще всего смещаются в область, отличную от профессиональной деятельности. Еще сложнее менять поведенческие модели и накопленные годами негативные привычки. Чем больше жизненный багаж человека, тем ему сложнее что-либо ломать в своих устоях. Мы же подсознательно пытаемся выбрать наиболее опытного соискателя, тем самым невольно усугубляя последствия его вплетения в новый коллектив. И это проблема.

Читать далее
Всего голосов 7: ↑6 и ↓1 +5
Комментарии 1

О процессе подготовки ИТ специалистов в ВУЗах. Взгляд работодателя, подсмотренный изнутри

Время на прочтение 8 мин
Количество просмотров 7.5K

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

Мы всегда кичились своим профессионализмом, а разбавлять его дилетантами, размывая, завоеванный трудом и потом авторитет, не вписывалось в наши представления об успешном видении бизнеса. Но время шло, мы с тоской смотрели на пролетающие мимо упущенные возможности, и помянув, об утопающих и вариантах их спасения, подались в наш региональный университет на свой страх и риск искать сотрудничества. Как оказалось, утечке ИТ мозгов из региона подверглись не только предприятия, но и ВУЗы. А посему, к нашей радости, в глазах руководства университета мы увидели, зеркальное отражение тоски, точь в точь сродни нашей.  В общем встретили нас радушно, с распростертыми объятиями, заложив смычку ИТ бизнеса с ИТ обучением. Таким образом ресурсный голод толкнул меня на тропу преподавательской деятельности. Я и до этого практиковал обучение, но среди действующих ИТ специалистов, повышая их профессиональный уровень отдельными внесистемными тренингами. А тут, мы подрядились сразу на ведение двух предметов, которые надо было читать системно, на протяжении года, шаг за шагом приближая студентов к совершенству. Работа длительная стратегическая, ставшая для маленькой такой компании, как наша, настоящим вызовом. Но, как оказалось, и в таком подходе можно отыскать множество своих плюсов. Из полуфабриката "Айтшника" с абсолютно не зашоренными стереотипами мозгами, чистыми бескорыстными душами, ежесекундно рвущимися в бой, оказалось можно лепить сотрудника, по образу и подобию, воображаемого нами идеала специалиста.

Вы не любите студентов? Вы просто не умеете их готовить.

Читать дальше
Всего голосов 15: ↑10 и ↓5 +5
Комментарии 56

Построение архитектуры социальной среды

Время на прочтение 11 мин
Количество просмотров 2.6K

Вступление


Вы все — система, которая так много знает. Вы решаете, что хорошо, а что плохо. Точно так же, вы решаете, что смешно, а что нет.

Джокер (Joker)

После публикации моей статьи «Социальный Организм — как форма эффективного взаимодействия команды», у меня состоялся целый ряд дискуссий с заинтересованными читателями на тему организации социальных взаимоотношений. Статья была построена в виде трех основных частей, посвященных: анализу самого явления «Социального организма», его основным функциям и практическим советам по построению и развитию подобного «Организма».

Предложенный вариант разделения Организации на две взаимодействующие системы: «Социальный организм» и «Производственной механизм», каждый из которых решает только присущие ему функции, вполне применим также к работе социальных сетей, сетевых игр, политических движений и прочих социальных коммуникаций.

К тому же новый тренд «самоизоляции и увеличения социальной дистанции» в значительной мере повлиял на Социальную реальность. Например, мне пришлось организовывать новые формы и способы преподавания и контроля успеваемости, среди своих студентов в университете.

В результате всех этих перипетий у меня родился целый ряд мыслей и выводов, которыми я хочу поделиться в данной статье.
Читать дальше →
Всего голосов 7: ↑6 и ↓1 +5
Комментарии 8

Психоанализ эффекта недооцененного специалиста. Часть 2. Как и зачем противостоять

Время на прочтение 12 мин
Количество просмотров 7.5K
Начало статьи с описанием возможных причин недооценности специалистов, можно прочитать, перейдя по «ссылке».

III Противостояние причинам, вызывающим недооцененность.


Вирус прошлого не поддается лечению – пока свое не возьмет, он не уйдет.
Но ему можно и нужно противостоять – предупредить осложнения.
Эльчин Сафарли. (Рецепты счастья)

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

Но, для начала, необходимо признать, что: «проблемы у меня есть и перечисленные в предыдущей главе признаки имеют место быть в моей профессиональной карьере». Можно конечно воспользоваться проверенным приемом и сказать себе, что это не у меня, а у парня по соседству, а я просто хочу ему помочь. Так тоже сойдет.
Читать дальше →
Всего голосов 22: ↑19 и ↓3 +16
Комментарии 10

Психоанализ эффекта недооцененного специалиста. Часть 1. Кто и почему

Время на прочтение 18 мин
Количество просмотров 17K

1. Вступление


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

Пока Вы читаете и никто не слышит, сознайтесь честно, Вы же сталкивались с подобными проблемами!

Дожив до возраста «Аргентина – Ямайка», пройдя путь от разработчика к системному аналитику, менеджеру проектов и до директора и совладельца ИТ фирмы, я частенько наблюдал подобную картину, но уже с оборотной стороны. Многие сценарии поведения недооцененного сотрудника и недооценившего его менеджера прояснились и стали очевидны. Многие вопросы, осложнявшие мне жизнь и мешавшие самореализовываться долгое время, наконец-то получили ответы.

Эта статья может быть полезной как самим недооцененным сотрудникам, так и их менеджерам.
Об авторских тренингах на тему: «Социальная инженерия» подробнее можно узнать на моем YouTube канале
Читать дальше →
Всего голосов 35: ↑24 и ↓11 +13
Комментарии 42

Анализ Agile. Мифы и действительность

Время на прочтение 22 мин
Количество просмотров 17K

I Вступление


Будку надо переносить! Сезона не бывает, чтоб пару-тройку не шандарахнуло.
То с туалетом путают, то с пляжной кабинкой…
(х/ф Особенности национальной рыбалки)

Конец года, подведение итогов, заполнение анкет и прочая предпраздничная мишура ИТ функционеров. Мне уже в который раз попадается на глаза итоговые опросники ИТ фирм, призванные выявить тренды в подходах к разработке продуктов. И каждый раз возникает ощущение какого-то подвоха, когда отвечаешь на вопросы типа: «Вы все еще пользуетесь методом Waterfall (водопадная модель), или Вы все-таки (как и все передовое человечество) практикуете Agile (гибкие методологии)». Когда же начинаешь выяснять у автора сего опроса, а что он понимает под Agile, его разъяснения как-то не сильно ложатся в канву манифеста (Agile Manifesto). О многих принципах он реально задумываются впервые и эти самые принципы прямо-таки ставят его в тупик. Но после небольшого замешательства, в ход идет тяжелая артиллерия с железобетонным обоснованием своей позиции: «Мы же не по Водопаду работаем, значит по Agile».

Сам тезис «Гибкие методологии» настолько гуттаперчевый еще в своем звучании, что многие пытаются втиснуть в него все что угодно, а вернее то, что им наиболее выгодно. Постепенно это стало модной ширмой, которой можно прикрыть всякие свои недостатки и даже разгильдяйство, в процессе производства ИТ продуктов, и при этом, как-бы оставаться на гребне волны, в тренде. Мол не мы такие – а методика такая.

Давайте вместе, еще раз “ударим анализом” по теме Гибких методологий, попытаемся разложить основные артефакты и принципы по полочкам и отделить, тот сакральный смысл, который закладывали в это понятие изначально, от того, во что его превращают отдельные нерадивые популисты. Так же сравним подходы Agile с другими методиками для более точного понимания той грани, что их разделяет или наоборот – объединяет. Заодно попробуем выяснить, где использование принципов Agile наиболее целесообразно, а где не совсем уместно?
Читать дальше →
Всего голосов 28: ↑20 и ↓8 +12
Комментарии 51

Сага об электронных услугах и местах их оказания. Часть 2. Электронный кабинет

Время на прочтение 7 мин
Количество просмотров 2.8K
В предыдущей части Часть 1. Электронная услуга мы разобрали, что из себя в целом представляет электронная услуга. Теперь поговорим о местах ее оказания.

III Организация комплексных электронных услуг

Где-то на самом низком уровне высокоцентрализованной организации, которой я руковожу, сидят люди, которые делают мою работу, и дело идет вполне гладко без особых усилий с моей стороны. Я полагаю, это происходит оттого, что я — хороший работник.
Джозеф Холлер
Итак, мы установили, что:

  1. Электронная услуга – это сервис, имеющий компьютерную или электронную форму предоставления, предназначенный для удовлетворения потребностей пользователя;
  2. Для качественного предоставления электронной услуги, сервис должен получить полную и достоверную информацию от ее потребителя. Для этого он должен предоставить формат, определяющий форму и состав данных, ожидаемых от пользователя;
  3. Электронные услуги могут взаимодействовать друг с другом без явного посредничества человека.

1. Организация взаимодействия электронных услуг


В жизни часто бывает так, что получение всего лишь одной простой услуги, не достаточно.
Читать дальше →
Всего голосов 11: ↑10 и ↓1 +9
Комментарии 1

Сага об электронных услугах и местах их оказания. Часть 1. Электронная услуга

Время на прочтение 8 мин
Количество просмотров 7.6K

I. Вступление

Уверен, если бы Смерть знала, что такое бюрократия,
люди бы никогда не умирали, вечно стоя в очереди…
Симбионт.
Недавно окунули меня в одну интересную тему, связанную с виртуализацией деятельности организаций, в хорошем смысле этого слова. Не предприятий, а именно организаций, как некоего объединения граждан, не важно коммерческого или общественного. Поскольку человек, втянувший меня в тему, тесно связан с услугами интернет провайдинга, то его лоббистский взгляд на виртуальное учреждение выражается в раздаче (небескорыстно конечно) всем субъектам, задействованным в нем, уникальных адресов. Как бы застолбить в виртуальном пространстве рабочие кабинеты. Что там будет в них происходить дальше, дело второе. Ну его интерес понятен. А в чем же в этой схеме интерес владельцев и клиентов этих кабинетов?

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

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

II. Анализ явления электронной услуги

Работать с людьми легко. Трудно работать с живыми людьми.
Александр Кулич.
Что же такое электронная услуга, в хорошем смысле этого слова?
Читать дальше →
Всего голосов 6: ↑6 и ↓0 +6
Комментарии 0

А не спроектировать ли нам систему для управления производством ИТ продуктов. Часть 3. Поддержка инфраструктуры

Время на прочтение 6 мин
Количество просмотров 4.2K
В предыдущих частях Краткое содержание:

«Часть 1»
I Вступление
II Анализ рынка решений
1. Стандартизация функций систем, представленных на рынке
2. Недостатки существующих систем
3. Вызовы при создании системы поддержки производства информационных систем

III Проектирование базовой структуры системы
1. Деление решаемых проблем по типам

«Часть 2»
2. Требования и задачи для них
3. Спецификации и задачи для них
4. Сборки и задачи для них
5. Анализ фазы проектирования


IV ПРОЕКТИРОВАНИЕ ЭЛЕМЕНТОВ ИНФРАСТРУКТУРЫ СИСТЕМЫ


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

Продолжим начатое в предыдущей части разрушение привычных шаблонов и конструирование других, новых.
Читать дальше →
Всего голосов 6: ↑6 и ↓0 +6
Комментарии 0

А не спроектировать ли нам систему для управления производством ИТ продуктов. Часть 2. Базовая структура решения

Время на прочтение 7 мин
Количество просмотров 3K
В предыдущей части «Часть 1» Краткое содержание:

I Вступление
II Анализ рынка решений
1. Стандартизация функций систем, представленных на рынке
2. Недостатки существующих систем
3. Вызовы при создании системы поддержки производства информационных систем

III Проектирование базовой структуры системы
1. Деление решаемых проблем по типам

2. Требования и задачи для них


Сперва сосредоточимся на проблеме, как может быть организована работа, касающаяся требований к создаваемому продукту. Ее исполнители и авторы скорее всего так или иначе завязаны на функции по сбору и анализу информации. Люди неординарные и немного консервативные, под них и будем подстраиваться.
Читать дальше →
Всего голосов 5: ↑5 и ↓0 +5
Комментарии 0

А не спроектировать ли нам систему для управления производством ИТ продуктов. Часть 1. Анализ коробочных решений

Время на прочтение 10 мин
Количество просмотров 7.4K

I Вступление

Ставишь себе невозможную цель и развлекаешься этим, если можешь. Ведь такое занятие интересно само по себе, поскольку изначально перед тобой заведомо невыполнимая задача, а что может быть увлекательней, чем невозможное
Иосиф Александрович Бродский.
За свою многолетнюю ИТ практику мне пару раз посчастливилось поучаствовать в проектах, затрагивающих тему автоматизации техпроцесса самого что ни на есть производства информационных систем. По разным причинам команде нужен был свой уникальный продукт, позволяющий выполнять подобные задачи. Например, в одном интересном проекте на платформе 1С, организуя процесс управления разработкой и внедрения ПО, требующий оперативности принятия мер (если что-то пойдет не так), помимо общепринятых активностей, мы создали подсистему, автоматизирующую сбор замечаний пользователей, непосредственно в самом продукте, так сказать на острие атаки. Прямо в свой рабочей среде, да что там среде, прямо на форме с конкретными данными, пользователи самолично могли создавать сообщения для разработчиков: об ошибках, замечаниях, предложениях и т.п. А там на обратном конце коммуникации, в глубоком тылу, программисты в системе управления разработкой, помимо описания ошибки, оперативно могли увидеть: сборку продукта, место локализации базы данных, форму, и наконец сами данные, с которыми связано возникновение ошибки. Это позволило разработчику прямо из задачи по устранению ошибки переходить в продуктивную среду и видеть воочую все то, что лицезрел пользователь, создавая сообщение. Согласитесь, что это очень удобно.
Читать дальше →
Всего голосов 11: ↑9 и ↓2 +7
Комментарии 6

Организация процессов производства информационных систем. Часть 4. Внедрение информационной системы

Время на прочтение 8 мин
Количество просмотров 19K

IX Внедрение информационной системы


Нет ничего труднее, опаснее и неопределённее, чем руководить введением нового порядка вещей, потому что у каждого нововведения есть ярые враги, которым хорошо жилось по старому, и вялые сторонники, которые не уверены, смогут ли они жить по новому.
Н. Макиавелли

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

Для начала реализованный продукт необходимо развернуть на оборудовании, уготовленном для организации его опытной эксплуатации.
Читать дальше →
Всего голосов 7: ↑6 и ↓1 +5
Комментарии 1

Организация процессов производства информационных систем. Часть 3. Реализация проектного решения

Время на прочтение 10 мин
Количество просмотров 7.2K

VII Разработка плана реализации и внедрения проектного решения


Блестящим планам везет на проектировщиков.
Скверным планам везет на исполнителей.
Веслав Брудзинский.

На этом этапе процесс вновь начинает крутиться вокруг руководителя проекта. Снова оценка трудоемкости, определение сроков, согласование объемов, утверждение порядка исполнения и т.п.

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

Для решения этих задач чаще всего разрабатывают план-график, позволяющий организовать и упорядочить взаимодействие команд и отдельных исполнителей в рамках всего проекта.
Читать дальше →
Всего голосов 10: ↑9 и ↓1 +8
Комментарии 0

Организация процессов производства информационных систем. Часть 2. Формирование проектного решения

Время на прочтение 8 мин
Количество просмотров 9.8K

V Разработка плана-графика проектных работ

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

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

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

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


Читать дальше →
Всего голосов 7: ↑7 и ↓0 +7
Комментарии 4

Организация процессов производства информационных систем. Часть 1. Отправная точка

Время на прочтение 14 мин
Количество просмотров 12K

I Вступление

Из хаоса каким-то образом рождается порядок.
Некоторые об этом узнают из газет со значительным опозданием, а некоторые по горькому опыту на месте и в процессе создания этого порядка.
Михаил Булгаков.
Просматривая статьи, посвященные той или иной теме, связанной с созданием программного обеспечения, часто наблюдаю, вот какую картину: узкая тема раскрыта интересно и профессионально, но вот когда задеваются нюансы на стыке, по ту сторону от основного вопроса, чувствуются рассогласованность и провалы в общем понимании процесса производства информационных систем. Разрываются причинно-следственные связи. Иногда, непонимание внешнего окружения обсуждаемого вопроса, вносит искажения в основную тему, ну или по крайней мере, затушевывает некоторые важные моменты, достойные внимания. Когда же вступаешь с автором в полемику, становится очевидным, что для него вопросы, выходящие за рамки его наблюдений и опыта, абсолютно неважны. Он просто упомянул всуе сопредельную тему, а дальше, как говорится, уже не его проблемы. Второй нюанс, на котором я хочу заострить внимание – пренебрежение масштабами замысла. Ведь то, что хорошо для реализации малых проектов, смерть для больших и наоборот. Этот факт часто попросту сбрасывается авторами со счетов. А в результате идут баталии с критиками решения, в которых каждый как бы и прав, но только с точки зрения своей отдельностоящей колокольни. Сами же точки зрения никак не обозначаются сторонами дискуссии, а потому никак не учитываются.

Исходя из всего вышесказанного, мне показалось, что будет весьма полезно собрать и описать структуру процесса производства программных продуктов (ну хотя бы основных вариантов), при этом не вдаваясь глубоко в специфические детали, а фабулу изложить в формате, предельно доступном для широкого круга лиц. Естественно данная публикация – это лишь мой взгляд на предмет.
Читать дальше →
Всего голосов 12: ↑12 и ↓0 +12
Комментарии 4

Информация

В рейтинге
Не участвует
Откуда
Симферополь, Республика Крым, Россия
Дата рождения
Зарегистрирован
Активность

Специализация

Chief Executive Officer (CEO), Systems Analyst
Lead