Разное

Проекты в it сфере – — АйТи

17.05.2017

Содержание

Как стать руководителем проектов в IT / Habr

Привет, друзья!

Так получается, что со мной периодически связываются мои знакомые и знакомые моих знакомых, которым меня порекомендовали, с примерно одним и тем же вопросом: «Как мне стать project manager’ом в IT, если до этого я работал(-а) на похожей позиции, но не в IT?».

Так как подобных запросов накопилось несколько штук за довольно короткое время, я решил написать об этом отдельную статью. Ну вы понимаете — я же ленивый, и теперь смогу сразу давать ссылку на этот текст, вместо очередного повторения уже несколько раз сформулированных ответов. Статья не претендует на универсальность — это только мой взгляд на ситуацию. В то же время скажу, что когда проводишь собеседования, нанимаешь и обучаешь project manager’ов — накапливается довольно много общих критериев, отвечающих на вопрос «А что же на самом деле должен знать и уметь IT project manager?», чтобы успешно работать в IT.

Кстати, знание английского языка в статье даже не обсуждается. Оно просто обязательно.

Поехали?

Как обычно выглядит запрос:

Алексей, добрый день! Меня зовут <…>. Мне посоветовал к Вам обратиться <…>. Нужен Ваш экспертный совет. Буду благодарна Вам за подсказку. Нашла тренинг для проектных менеджеров, который Вы читаете. Хотела бы спросить стоит ли проходить мне его. Кратко о моей ситуации: <…> хотела бы себя попробовать дальше развивать в проектном направлении, но уже в IT-сфере. Уже проходила несколько собеседований, но пока безуспешных (работодатели часто ссылаются на то, что нет опыта в IT). В связи с этим у меня возникла мысль о том, как заставить все-таки поезд тронуться. Буду очень благодарна за совет по поводу курсов. Возможно есть смысл посмотреть что-то смежное к менеджеру проекта, если нет шансов, чтобы взяли в IT-сферу на такую позицию? Буду благодарна за любую обратную связь.

Варианты обращений отличаются только предыдущим опытом работы в неких не-IT областях.

Что я могу посоветовать?

Сначала напугаю и сгущу тучи.

1. Действительно, почти всегда отказывают ровно потому, что для project manager’a в IT крайне важно разбираться не только в project management’e как таковом, но еще и в IT. Это требуется ровно для двух вещей: а) для нахождения общего языка с подчиненными (тестировщики, аналитики и разработчики, которые все айтишники) и соответственно понимания сути диалогов, спецификаций, проблем и прочего, и б) для нахождения общего языка с представителями заказчика, которые зачастую точно также имеют в основном айтишный background. Конечно, есть некоторые небольшие шансы убедить будущего работодателя, что понимания специфики IT-области не критично для данной позиции. Важно помнить, что эти шансы очень и очень небольшие. Все-таки наниматель лучше знает, что ему надо, и убедить его в другом — довольно сложно. Особенно работодателей в IT — они уж точно знают, какой именно сотрудник им нужен. В то же время, никто не запрещает пробовать убеждать. Вдруг получится?

2. В IT очень важным является понимание этапов разработки продуктов (SDLC — Software Development Life Cycle). Работая в НЕ-айтишных организациях это понимание полностью получить, увы, невозможно. Есть моменты специфичные для IT-отрасли. А раз project manager в IT отвечает за разработку продукта/кода/функционала к заданному сроку, с заданным качеством и в заданных рамках по качеству/функционалу, то ему обязательно понимать, как же достичь всего этого теми средствами, которыми он обычно располагает в IT-сфере. В других отраслях могут быть свои нюансы, отличающиеся от IT в ту или иную сторону.

3. Любые тренинги по управлению проектами «вообще», скорее всего не сильно помогут. Нужны тренинги по управлению проектами в IT. Поясню почему я так считаю: тренинги «вообще» не дадут понимания двух важных вещей: «айтишного технического языка» и «понимание этапов разработки именно в IT».

4. В любой IT компании, уже есть свои сотрудники, желающие стать руководителями. И эти сотрудники (разработчики, тестировщики, аналитики) — уже разбираются в IT (владеют тем же техническим языком, что и окружающие), а также знают SDLC. Более того, они знают заказчика, знают специфику компании и ее внутреннюю кухню (это не критичные пункты, но сравнивая с нулевыми знаниями внешнего кандидата — даже эти пункты могут перевесить). Таким образом получается, что внешний кандидат НЕ из IT-отрасли вынужден конкурировать как с внутренними кандидатами изнутри самой компании, так и с другими внешними кандидатами, тоже из IT-отрасли.

Итак, какие же параметры получились?

1. Владение техническим IT-шным языком. Понимание, к примеру, что вообще такое FTP, Signoff, Sprint, ASAP, Regression, XML, Database request, Deadline, FYI, Client-Server Architecture, Redline, Smoke Test, FTE, Release… Список можно продолжать бесконечно. Быть супер специалистом в некоторых упомянутых вещах — совсем не требуется. Требуется понимание сути, что это такое вообще, что за термины, что они обозначают, что за ними стоит, иначе бы будете как слепой в мире зрячих.

2. Знание SDLC (Software Development Life Cycle) — этапов разработки программных продуктов. И не просто знание, а понимание, почему именно такие этапы, почему именно в таком порядке, где и почему можно перескакивать с одного этапа на другой и можно ли двигаться по этим этапам в обратную сторону, и если да, то когда и при каких условиях.

3. Методологические навыки управления проектами и людьми (PM Hard Skills). Сюда входят знания методологий, принципов управления и процессов по областям. Таких как Agile, Scrum, Kanban, Waterfall, Communication management, Specification & Requirements management, Change management, Risk management, Reporting и т.п. Хорошая новость — всему этому так или иначе можно научиться на соответствующих тренингах, вебинарах и множестве доступных онлайн материалов.

4. Личностные навыки управления проектами и людьми (PM Soft Skills)

. Сюда входят Team & Client management skills, Ability to solve complex tasks, Presentation skills, Conflict management skills, Communication skills, Feedback skills, Ability to hear, listen & understand, Openness to other points of view, Ability to admit own mistakes and to correct them, Self-criticism, Leadership skills, Coaching/Mentoring skills, Ability to explain, Professional culture (quality of speech, emails, calls), Ability to make decisions and take responsibility for it, Pro-activity, Task management skills, Delegation skills, Execution control skills, Personal effectiveness, Time management skills. Вторая хорошая новость — всему этому тоже можно научиться на соответствующих тренингах.

Составим сводную таблицу, в которой будут присутствовать три кандидата:

  1. внешний без знания IT-отрасли
  2. внешний со знанием IT-отрасли
  3. внутренний со знанием IT-отрасли и специфики компании

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

Мое мнение, что без погружения в IT-среду невозможно овладеть IT-шным языком хотя бы на уровне понимания. Таким образом с первым пунктом конкурировать нет смысла. Вы (внешний не IT кандидат) тут гарантированно проиграете. Остальные три области — вполне поддаются конкуренции. Причем если вторая (знание SDLC) тоже требует погружения в среду для полного понимания, то хотя бы примерно разбираться в ней не работая в IT — научиться можно. Недостаток знаний SDLC можно компенсировать за счет знаний толкового технического-лида, архитектора да и вообще любого технически грамотного человека из вашей будущей команды. А вот чтобы найти с таким человеком общий язык и получить его помощь — нужны очень серьезные навыки в PM Soft Skills.

Остаются PM Hard Skills и PM Soft Skills — и это ровно те области, где не IT-кандидат может значительно переиграть кандидата из IT-отрасли. Почему я так считаю? Многие руководители из IT — выросли из разработчиков, аналитиков, тестировщиков. Да, среди них есть очень крутые специалисты. Многие такие кандидаты в менеджеры из IT отрасли — они в глубине души остаются теми же самыми программистами, аналитиками и тестировщиками. А это говорит о том, что как раз PM Hard и Soft Skills у них могут быть развиты слабее, чем у внешнего кандидата. Ведь обе эти области (PM Hard Skills и PM Soft Skills) не зависят от IT специфики. Их можно и нужно развивать независимо от области, где вы сейчас работаете.

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

План действий, который может помочь (а может и не помочь). Но если совсем ничего не делать — не поможет гарантированно.

1. Поговорить с кем-то из ТОЛКОВЫХ знакомых айтишников (разработчиков, тестировщиков, аналитиков, а еще лучше тим-лидов или менеджеров) про SDLC. Дополнительно почитать об этом в Интернет. Возможно, стоит поговорить не раз и даже не два.

2. Попробовать выбрать роль ассистента project manager’a в IT, либо роль младшего PMO-специалиста (там важнее знание процессов управления, чем знание этапов и нюансов и терминов разработки). Попав на любую из этих ролей — необходимо будет уже изнутри изучать терминологию и специфику IT, если действительно есть сильное желание двигаться и развиваться именно в этой области.

3. Объяснить на собеседовании, что «Твои сильные стороны — это умение решать конфликты, навык работы со сложными ситуациями, успех в переговорах, знание английского языка. А технические пробелы в знаниях ты будешь закрывать за счет правильной коммуникации и помощи от технических специалистов, которые будут твоими подчиненными. Ведь работа с людьми — это твой конек». Примерно такими словами. Важно, чтобы это была действительно правда про сильные стороны, а не бравада для прохождения собеседования. Поверьте — любой толковый руководитель определит на собеседовании, если вы обманываете. И на этом все закончится. Но допустим вы получили работу — тогда необходимо срочно искать союзника среди технарей, который будет помогать полностью покрывать и регулярно объяснять техническую сторону работы, задач и возникающих сложностей.

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

Резюмируя. Чтобы конкурировать с ребятами, которые разбираются в IT и тоже стремятся стать project manager’ами — необходимо серьезно превосходить их в PM Soft Skills.

P.S.: оригинал этой статьи (и другие интересные материалы) можно прочесть в моем блоге: consultpm.com
P.P.S.: мне резонно заметили, что IT не ограничивается разработкой. Это верно. В таком случае второй пункт (знание SDLC) будет менее значим, либо совсем заменен на какой-то свой, специфичный именно для вашего направления.

Поделитесь этой статьей с друзьями.
Спасибо и успехов вам!

habr.com

особенности, характеристики, эффективность и примеры

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

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

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

Сущность и объективность ИТ проекта

Принято считать, что бизнес или компания — это определенная инфраструктура. В первую очередь, это:

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

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

  • разработка (развитие) программного обеспечения;
  • внедрение информационных систем;
  • проекты инфраструктурного и организационного характера.

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

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

Объективная действительность ещё до появления компьютерной техники четко определила: информация — это суть всего, что живет (существует) и развивается. От того, как это развитие отражено в реальном проекте зависит результат, для достижения которого он разработан.

Финансовая сторона проекта

Анализ и оценка ИТ проектов как исполненных (по факту затрат), так и подготавливаемых (по предполагаемым инвестициям) свидетельствуют о высокой стоимости, но не всегда адекватной отдаче от внедрения. Риски потратить значительные средства впустую очень велики.

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

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

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

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

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

Области применения ИТ

Нельзя говорить, что ИТ проекты — это бухгалтерия, экономика и делопроизводство. Скорее — это три направления, в которых разработчики ещё будут долго идти к совершенству и что там за горизонтом ещё мало кому видно.

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

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

Пример 1. Пропускная система

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

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

Реализовать такой ИТ проект, который объединит всё пропускное хозяйство по всем обособленным подразделениям в единую систему, несложно. Вопрос времени, и высшее руководство будет всегда знать, кто и когда пришел на работу, а сотрудник может пройти со своим пропуском в любое подразделение в любом городе.

Пример 2. Периметр защиты инфраструктуры

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

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

При формулировке такого рода задач риски ИТ проектов существенно ниже, если команда разработчиков берет за основу уже проверенные и реализованные идеи, а не разрабатывает «своё мнение» с самого начала.

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

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

Пример 3. Веб-ресурсы: управление и представление

Сайты — это недавнее прошлое и представление о том, что сайт — это ресурс в интернете давно устарело. Сегодня веб-ресурс — это активная точка в локальной или глобальной сети, что не меняет его нового статуса — это элемент управления инфраструктурой компании или лицо компании для её клиентов, партнеров или просто посетителей.

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

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

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

Пример 4. Модернизация действующего ПО

Эта грустная область ИТ проектирования. Удивительно, но по сей день жив и работает не только Clarion из далеких 80-х, Access времен расцвета Бейсика и FoxPro по всей линейке версий от 2.6 до Visual FoxPro 6.0 (хитрая лиса).

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

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

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

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

Характеристики ИТ проектов

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

Обширные теоретические исследования по действующим веб-ресурсам, форумам и знаниям экспертов в области ИТ проектирования, несомненно, имеют значение.

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

Путь от начала формулировки цели ИТ проекта до финального решения должен характеризоваться только тремя объективными обстоятельствами:

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

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

Динамика и самоадаптация в ИТ проектировании

ИТ проекты, примеры решений, результаты внедрений — это не статика.

В частности веб-ресурс — это не сайт с фиксированным меню, функционалом и количеством страниц. Если это так, то результат будет краткосрочным и не перспективным.

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

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

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

При внимательном рассмотрении такой перенос центра тяжести — есть реализация объективного и эффективного правила: идеальное решение — не принимать никаких решений, но качественно предоставить возможность принимать решения другим, в данном случае, потребителям.

fb.ru

41 Проектное управление в сфере ИТ. Виды проектов разработки и внедрения ИС. Команда ИТ проекта

Скачать ZIP архив | Скачать RAR архив

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

Для более эффективного достижения целей компании создается система управления проектами.

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

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

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

Виды проектов в разработке и внедрении ИС

По объекту проектирования ИТ-проекты можно разделить на три группы:
— проекты по развитию ИТ-инфраструктуры
— проекты, связанные с бизнес-приложениями — внедрение новой (замена существующей) ИС (бизнес-приложения)
— организационные проекты — разработка ИТ-стратегии
Построение на базе СКЬ

Проекты разработки ИС

В связи с этим ИТ-проекты разработки можно разделить на следющие группы:
1) Проекты по проектированию информационных систем.
2) Проекты по разарботке программного обеспечения.
3) Проекты модификации информационных систем.
4) Комплексные проекты.

Проектирование информационных систем, в результате получаем пакет документов из:
1 Первначальный анализ требований к системе.
2 Создание функциональной спецификации
3 Разработка технического задания.

Разработка программного обеспечения.

Разработку ПО можно разбить на четыре основных этапа:
1 Планирование разработки.
2 Разработка функциональности.
3 Проверка качества (тестирование).
4 Введение в эксплуатацию.

Модификация информационных систем

Модификация ИС — это изменение и улучшение уже существующего решения.

1 Оценка существующего решения.
2 Составление технического задания на модернизацию.
3 Планирование модернизации.
4 Модернизация.
5 Тестирование.
6 Внедрение модернизованного продукта.

Комплексные проекты по разработке информационных систем.
В зависимости от способа реализации все проекты по разработке ИС могут быть разделены на:
1) проекты собственной разработки
2) аутсорсинговые проекты

Проекты внедрения ИС

Основные этапы внедрения ИС:
1 инициализация проекта
2 анализ существующих бизнес-процессов
3 проектирвоание системы
4 реализация
5 подготовка к эксплуатации
6 поддержка эксплуатации

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

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

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

Руководитель проекта нужен во всех проетках.

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

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

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

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

Технический лидер — самый опытный разработчик в команде.

Руководитель ИТ-подразделения отвечает за поддержку и работу продукта, разработанного в проекта…

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

Проектные команды

Заказчик:
1 Руководитель проекта
2 Внутренний лидер ; Архитектор проекта
3 Руководители ИТ-подразделения ; Ведущий представитель пользователей
4 Специалист по заключению контрактов

Разработчик:
1 Руководитель проекта
2 Технический лидер группы ; Архитектор
3 Аналитик требований ; Разработчик
4 Управление конфигурацией ; Тестировщик
5 Специалист по инструментальным средствам

Методология Microsoft Solutions Framework (MSF) предлагает модель проектной группы, состоящую из шести ролевых кластеров:

1 управление продуктом
2 управление программой
3 разработка
4 тестирование
5 удовлетворение потребителя
6 управление выпуском

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

konyakov.ru

IT — проект со школьниками: несколько рекомендаций / Habr


За последние 5 лет мне удалось создать десяток учебных проектов вместе со школьниками 8-11 классов в сфере информационных технологий. И вот я решил поделиться своим опытом в этой статье, надеясь на конструктивную беседу по такой актуальной теме. В статье я попытаюсь раскрыть технологию реализации IT — проекта как способа обучения, а также затронуть технические аспекты, которые помогут вашей команде достигнуть результата.

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

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

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

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

Идея и продукт


Отнеситесь к выбору темы своего проекта внимательно и тщательно. Зачем тратить впустую ближайшие несколько месяцев, верно? Цели могут быть совершенно разные: улучшить мир, выиграть конкурс, заработать денег, но вся ваша команда должна четко понимать, зачем вы тратите силы и ресурсы, создавая что-то новое.

Еще один неочевидный момент: когда вы создаете что-то осязаемое, гораздо выше вероятность того, что проект будет реализован. Очень часто случается так, что, загоревшись идеей, команда не доводит дело до конца, просто четко не понимая, а что же мы делаем?

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

Темы проектов могут быть очень разными, и очень большую роль здесь играет наставник. Школьник в силу отсутствия опыта просто может не понимать значимость (или отсутствие таковой) той или иной темы. Школьник может делать что-то только ради процесса, не отдавая отчет в бессмысленности создаваемого. Например, давайте сделаем так, чтобы свет в комнате включался по хлопку ладонями? Интересная идея, но спросите себя, а зачем, кому это будет нужно, если таких решений уже пруд пруди. Ради изучения чего-то нового? Да, такую цель тоже можно достигать проектной деятельностью, но она не самая главная. Главное, на мой взгляд, — научить ребят творить и создавать что-то нужное. Анализировать, аргументировать, убеждать и отстаивать свою точку зрения. Искать варианты улучшения существующего, создавать новое. Людей, которые могут придумывать, не так много, и ценность подобных специалистов возрастает с каждым годом.

Итак, что же может быть продуктом учебного проекта в сфере информационных технологий? Выделим основные очевидные варианты.

Сайт


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

Мобильное приложение


Еще интереснее и сложнее, чем сайт. Поле для фантазии не ограничено, причем, всплывает такой интересный момент: вы можете заниматься созданием проекта озеленения территории вашего микрорайона, но оформить результат как мобильное VR — приложение с возможностью “прогуляться” по создаваемой территории для более полного погружения в реализуемую концепцию. Что мы изучаем? Современные тенденции дизайна, объектно — ориентированное программирование. И, конечно, новые инструментальные средства разработки. А заодно и ландшафтный дизайн.

Компьютерная игра


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

Программа


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

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

Фильм, плакат, журнал, трехмерная визуализация — все это может стать результатом вашего проекта.

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

Формулировка концепции


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

Общие папки


Обязательно создайте для своего проекта облачное хранилище с совместным доступом участников. Если это Google Диск или Облако Mail.ru, то создайте общие папки. В одном проекте у нас их было 8: “Модели”, “Текстуры”, “База данных”, “Фоны”, “Картинки”, “Скрипты”, “Настройки”, “Общее”. Можно использовать, наверное, более продвинутые инструменты, например, Битрикс24, я не пробовал. Надо, кстати, обратить на это внимание. Наверняка, есть еще инструменты совместного ведения проектной деятельности.

План реализации


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

Нарисуйте результат


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

Назовите команду


Обязательно дайте название своей команде! Это сплотит участников. По возможности, выберите логотип, хотя бы из бесплатных, и создайте лозунг, девиз. Пусть вы будете “IT гуру” или “Кодята”, но название команды даже из двух человек может стать началом целой истории. Обязательно придумайте название вашего конечного продукта, пусть оно будет емким и хлестким. “Газонокосилка 2.0”, “Веб заметки” или “Погода в кармане”. Да, обязательно разделите функции внутри вашей команды: пусть кто-то создает дизайн, а кто-то пишет код, кто-то ищет аналоги и тексты, а кто-то подбирает фотографии или звуковые файлы.

Добавляем экономику


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

Выбираем инструменты


План есть, эскизы есть, теперь самое время выбрать программные средства для реализации проекта. Почитайте, что сегодня используется в реальной разработке, что в тренде, что пригодится участникам проекта потом. Попробуйте различные IDE и редакторы, но не зацикливайтесь на учебной программе, выйдите за ее рамки. Обратите внимание, что многие разработчики идут навстречу образовательным организациям, просите у них бесплатные версии их продуктов. Так делает Autodesk и JetBrains, например. Посоветуйтесь с экспертами. Делайте учебный проект правильными инструментальными средствами.

Версионный контроль


Если будет код, то обязательно создайте репозиторий для версионного контроля. Это сэкономит кучу времени, и ребята приучатся к этой технологии. Как-то я заметил, что переход на систему версионного контроля кода изменило мое отношение к тому, что я пишу. Код стал для меня очень важным и ценным, что ли. Каждое изменение стало более обдуманным. Удаление кода тем более. Более ценным становится и время на разработку. Храните все файлы удаленно и в совместном доступе.

Создаем прототип


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

Тестируем


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

Доделываем


Смотрим на часы. Оцениваем сроки и доделываем проект в соответствии с план — графиком. Причем, у вас могут быть как краткосрочные цели (выиграть ближайший конкурс), так и долгосрочные (доделать все до конца и выпустить продукт в свет). Дорабатываем основное, вспоминаем пожелания и выбираем из них самые критичные.

Презентуем


Все готово, отведите время на создание доклада и презентации. Рекомендую придерживаться вот таких разделов в презентации:
  • Введение: рассказываем основные положения, назначение проекта, рассказываем о команде;
  • Актуальность: говорим о том, насколько проект полезен и что достигаем, меняем, улучшаем его реализацией;
  • Цели: тут рассказываем аудитории, а какие же цели были или будут достигнуты реализацией проекта;
  • Задачи: показываем те задачи, которые были выполнены во время работы над проектом;
  • Обзор аналогов и прототипов: показываем уже существующие решения и говорим о том, чем ваше отличается от остальных;
  • Выбор инструментальных средств: в этом разделе презентации обосновываем свой выбор инструментов разработки;
  • Экономическая часть: немного говорим о деньгах, чтобы аудитория оценила степень реализуемости проекта;
  • Целевая аудитория: рассказываем о вашем потребителе;
  • Показываем продукт: тут надо отвести время для демонстрации работы созданного решения;
  • Планы развития: рассказываем о том, чем будем заниматься дальше. Можно планы разбить на несколько очередей.

Все, проект готов!

Шарик-то сдувается


Все хорошо на бумаге, но в реальности всегда чуть сложнее. На пути реализации проекта со школьниками встает несколько проблем. Первая — а когда делать? Вариантов несколько, может, это будет в рамках кружка, может, это будут старшеклассники в классах без экзаменов (8-ые и 10-е классы), может, на каникулах.

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

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

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

habr.com

Проектный менеджмент в IT — как это?

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

Из множества методологий нужна одна оптимальная и настроенная лично под нас и наш проект. Одно дело выполнять шаблонные задачи строго по скриптам из книги, другое — методом проб и ошибок вырабатывать свои специальные инструменты для учета приоритетов компании. Поэтому проектный менеджмент (PM), то есть методология управления компанией с делением всей работы на проекты, становится популярным во всех отраслях.

Что такое проектный менеджмент

Многие компании только сейчас переходят от классической (отработанная, часто бюрократическая схема) к проектной (каждая задача отдельно, делегирование ответственности) модели управления. Общий менеджмент для предпринимателя сводился к тому, что есть руководитель и исполнитель задачи. Дисциплина взаимодействия зависела от того, как прописано в шаблоне. Шаблон же был вбит в разумы всех одинаково лет этак 20-30 назад. Только этот шаблон уже не применить к новым условиями мирового рынка.

Исторически все началось с того, что в период перестройки 90-х годов сама логика ведения бизнеса была нарушена настолько, что попытки построить новую рабочую концепцию управления в миллениум создали термин «компания-однодневка». Концепции таких компаний проверялись на прочность и только одна из 10 компаний существовала больше полугода в 2000-х. Параллельно оставались многолетние предприятия, кардинально меняясь каждые лет 5 чтобы выжить в период перемен.
В 2010-х информационный взрыв интернета сделал доступной всю разрозненную базу наработок европейского и американского бизнеса. Из тонн полезной и мусорной информации вроде «что такое управление проектами и современный менеджмент», «как распределять обязанности, правильно предугадывать и сокращать риски» предприниматели до сих пор выбирают крупицы знаний, применимых именно в их компаниях.


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

В IT project management (PM) — это дисциплина, что объединяет процедуры, принципы и политику ведения бизнеса. Она руководит проектом от разработки концепции до завершения проекта.

Общий (функциональный) и проектный менеджмент отличается тем, что:
  • функциональный стабилен. Цель: поддержать и преумножить. Есть отработанный шаблон, он работает постоянно.
  • проектный изменчив. Цель: результат любой ценой. Есть deadline.

Причиной перехода от общего менеджмента к PM чаще других становится надежность — вместо относительной абстрактной перспективы к предсказуемым результатам.

Международная Ассоциация Управления Проектами (IPMA) провела исследование, по результатам которого новый подход сэкономит вам около 20-30% времени и 15-20% ресурсов.

Управление IT проектами vs другие сферы бизнеса

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

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

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

В IT проектный менеджмент может идти по трем жизненным циклам проекта:
  • Прогнозируемый, он же waterfall. Традиционный подход, даже в 2010-х применяется на порядок чаще других. Поэтапный линейный алгоритм.
  • Итерационный. Современный подход, в котором расширение функционала разрабатываемого программного обеспечения с каждым новым выпуском в рамках проекта.
  • Адаптивный. Agile, Scrum и другие методы. Цели компании и стратегия развития может меняться независимо от первоначального плана.

Основы управления проектами и необходимые компетенции

Составлять собственную систему или применять существующую методику к руководству проектами — решать вам.

Для начала опишите свой проект по 10 функциям управления проектами:
  1. Интеграция структуры проекта. Ключевая проблема, которую решает проект. Его результат и этапы (сгруппируйте их по смыслу). Разделяй, объединяй и властвуй.
  2. Масштаб и объем работ. Количество планируемых задач, потоков и приоритеты.
  3. Время. Сроки и хронология зависимых задач, ключевые этапы.
  4. Стоимость. Себестоимость проекта (ресурсы и человеко-часы).
  5. Качество. Критерии и оценка.
  6. Закупки. Ресурсы, логистика.
  7. HR. Люди. Навыки, потенциал и продуктивность.
  8. Коммуникация. Отчет руководству, взаимодействие между персоналом.
  9. Риски и потери. Предусмотри и предотврати.
  10. Заинтересованные стороны. Инвесторы, акционеры, директора и клиенты.

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

Методологии управления IT проектами

Главный выбор предпринимателя при разработке программ и приложений — это подходящая методология управления. Их действительно много, на 2017-й год существуют:

Традиционные методики:

PMI / PMBOK «Метод». Инициирование, планирование, исполнение, контроль и закрытие. Инструкция, не метод по сути.

Гибкая методология:
Методики по управлению изменениями:
Процессно-ориентированные методики:
Другие индивидуальные методики и гибридные подходы:

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

Процесс управления проектами в IT

Разрабатывать и внедрять PM в компании стоит постепенно, проверяя на практике каждый этап и взаимодействие.

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

Все процессы управления проектами также происходят постепенно и проходят 5 этапов:
  1. Разработка концепции, инициирование.
  2. Определение и планирование.
  3. Запуск работы и воплощение задуманного.
  4. Контроль и наблюдение.
  5. Закрытие проекта.

Организация управления IT-проектом

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

Самое грубое деление классической модели ролей:
  • Владельцы.
  • Исполнители.
  • Потребители.

В коммерческих компаниях выделяют такое понятие как заинтересованная сторона. Все, кто влияет на результат и прибыль. Это стейкхолдеры (stakeholders).

Внутренние:
  • Учредители.
  • Инвесторы.
  • Персонал.
Внешние:
  • Поставщики.
  • Посредники.
  • Потребитель (клиенты).

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

Все участники проекта, причастные к его созданию и потреблению, разделяются на:
  • Заказчик. Главный. Принимает все ключевые решения.
  • Собственник. Владелец всех прав собственности на продукт проекта. Часто — заказчик.
  • Инициатор. Его идея становится проектом. Любой участник проекта может им быть. Права у заказчика.
  • Родительская (головная, материнская, постоянная) организация. Организация, в которой возник и будет проект.
  • Спонсор. Предоставляет финансирование. Обеспечивает материальные ресурсы.
  • Инвестор. Вкладывает финансирование ради личной прибыли от реализации проекта.
  • Управляющий (менеджер проекта). Лично ответственный за проект перед заказчиком. Имеет право принимать решения сам.
  • Команда управления. Руководители среднего звена.
  • Команда. Исполнители. Создают продукт.
  • Контрактор, Субконтрактор, Подрядчик. Исполнитель по контракту.
  • Клиент. Потребитель продукта.

Инструменты для управления IT проектами

В Америке сервисы для ведения бизнеса существуют с 1987 года, у нас же заветная 1С появилась лишь в 1991 году. Развитие технологий от автоматизированного бухгалтерского учета и CRM для call-центров до полноценной виртуальной среды централизованного контроля и взаимодействия в компании было долгим, но плодотворным.

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


Самые популярные конкуренты среди сервисов в странах СНГ Bitrix24, Trello, Asana, Basecamp и Worksection.

Изюминка разных технологий в том, что в них можно найти:
  1. Диаграмму Ганта для определения дедлайнов и связанных временем задач, как реализовано в Worksection.
  2. PERT диаграмму для оценки и анализа алгоритмов и способов реализации проекта.
  3. Автоматические отчеты, канбан-доски, встроенные файловые системы и многое другое.

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

Вердикт

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

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

Внешние — форс-мажоры.

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

Внутренние — поломки внутри компании, которые на уровне управления сводятся к трем выводам:
  1. Никто не знает, чего хочет, пока не попробует это. Даже самое точное ТЗ не отразит все ожидания. Даже лучший продукт найдет недовольного пользователя.
  2. Попробовав, мы хотим изменить. Многие идеи возникают только в процессе личного опыта и экспериментов. Помните: если мишень движется, стоит сдвигать прицел.
  3. Даже самому большому проекту будет брошен вызов конкурентом. Чем крупнее проект, тем легче ему провалиться. Сегментируйте, дробите, детализируйте.
Короткие итерации с фиксированным дедлайном легче контролировать, выполнить и исправить.

worksection.com

Менеджмент ИТ-проекта / Habr

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

На хабре есть много тем по специфичным аспектам менеджмента проектов. Но именно основы менеджмента до сих пор не были освещены.

Попробуем закрыть этот пробел.

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

UPD. Пост про менеджмент, а не про менеджеров.

  • Чем управлять
  • Основной процесс менеджмента
  • Нет делегирования? И это хорошо
  • Малая боевая диверсионная группа
  • Системный анализ
  • Divide et Empera
  • Логгирование
  • Оценка множественных и неявных факторов
  • Время, как основной фактор
  • Два в одном

Менеджмент — это управление. В нашем случае, управление проектом.
Понятно, что управление проектом — это работа над его составляющими.


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

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

  • До начала процесса необходимо формализовать исходные данные и выделить цели.
  • Этап анализа является опциональным. Он проводится, в зависимости от масштабов и цены процесса. Если процесс дорогой — все исходные данные подвергаются детализации, информация дополняется схемами и резюме.
  • На этапе планирования выбираются методы решения задачи, определяется, как именно будет осуществляться процесс.
  • Для обеспечения корректности приемки еще на этапе планирования составляется чеклист — список критериев, который однозначно дает понять, что проект завершен.
  • Естественно, исполнителю должна быть доступен максимальный объем информации, связанный с процессом, в котором он участвует — исходные данные, цели и требования в чеклисте.
  • Если процесс не является непрерывным — по достижению целей он может быть завершен.
  • При повторном выполнении процесса к исходным данным добавляются результаты предыдущей итерации.


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

В условиях стартапа, как правило, делегирование в общем понимании недоступно. Слишком мало денег, слишком мало людей.

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

Поэтому, для обеспечения эффективности менеджмента (удачного управления проектом) целесообразно уделять большее внимание другим доступным методикам:
— системный анализ;
— интерактивный контроль;
— управление рисками.


На самом деле работа в условиях ограниченных ресурсов является более эффективной.

1. Избыточные ресурсы расхолаживают
2. В малой группе короче и эффективнее коммуникации
3. Малую группу легче настроить на цель
4. В малой группе эффективнее контролируются процессы
5. В малой группе проще охранять коммерческую тайну

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

Не надо стесняться малого размера вашей команды. Вообще, никаких комплексов! Только энтузиазм, только объективизм.


Благодаря методу системного анализа малые рабочие группы решают сложнейшие задачи. Причем делают это быстро и дешево.

Я не призываю вас создавать тонны трудночитаемой документации. Но использование даже некоторых основных методик даст вашему проекту жизнь. Вот эти методики:
— разделение задач на подзадачи;
— выделение субпроектов;
— запись (логгирование) всего.

Цели системного анализа таковы:
— получение прозрачного и очевидного представления всех деталей проекта;
— выявление потенциально узких мест;
— выявление скрытых факторов, прежде всего затрат;
согласование тактического и стратегического видения между всеми участниками проекта.


«Разделяй и влавствуй», завещали нам древние правители. И по сей день эта методика управления проектами оказывается одной из самых эффективных.

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

Для каждого аналитического элемента, для каждого фактора и подзадачи формализуются три вопроса: цель, объекты и методы. Оценивается масштаб, важность и сложность задачи. Если задача является сложной, масштабной или критичной — она делится на подзадачи или выделяется в отдельный проект.

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

Совершенно нормально, когда в результате разработки плана действий содержание проекта пересматривается.


Записывать имеет смысл все и всегда. В текстовом редакторе, в еверноте или в специализированном ПО — не важно. Главное — записывать, и регулярно осведомляться о том, что с записями осведомлены все ключевые участники проекта.

Все подряд записывал не только Сталин, но и все продвинувшиеся ученые, предприниматели и подвижники.
Дана Скалли подробно записывала на диктофон процесс вскрытия инопланетян, и заметки по расследованиям. Если вам в какой-то момент станет скучно писать — вспомните ее.


При оценке рисков, а также выборе стратегических и тактических решений нужно оценивать неизвестные, неявные или сложные (многокомпонентные) факторы.

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

Одним из таких приемов является применение оценок-весов.

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

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


Называя что-то «дорогим», программист подразумевает затраты ресурсов машины или сети. Аналогично, менеджер ИТ-проекта имеет в виду время. Буквально — время является основным измерением, для которого можно применять оценки вида «дорого» или «приемлемо».

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

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

Подробно этот вопрос раскрыл в посте про управление рисками.

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

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


Подготовительные мероприятия и проект в рабочем режиме — это два разных проекта!

Естественно, работать с ними имеет смысл по отдельности. Естественно, сначала имеет смысл спроектировать второй, и только потом — первый. В подавляющем большинстве стартапов совершаются лишние действия, лишние траты. А их не так уж сложно уменьшить — если сначала сосредоточиться на вопросе «что мы хотим иметь», и только потом — «как мы это хотим получить».

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

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

Пакет действий, необходимый от нуля до открытия проекта — в первую часть.

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

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

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

Подготовительные работы Основной процесс
Покупка ПО или программирование Поддержка технического обеспечения
Дизайн Бизнес-модель, план доходов и план расходов
Исследования, первое планирование маркетинга и рекламы Маркетинг и выполнение плана рекламы
Определение состава специалистов ФОТ

Оба процесса имеют итеративные признаки и общие объективные черты, но в то же время имеют массу различий.

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

  • Раздельные оценки затрат для двух этапов
  • Раздельные временные оценки (время до получения прототипа, альфы, беты, открытие, время до рентабельности)
  • Оценка бизнес-модели и ее детальных параметров
  • Оценка затрат на маркетинг и рекламу до открытия проекта и в процессе

Календарный план-график обычно составляется по кварталам.
В процессе бизнес-планирования имеет смысл попытаться спрогнозировать развитие проекта хотя бы на 1-2 года вперед. Но это уже другая тема.

Может быть что-то упустил? Дайте знать — напишу в следующих темах.

Спасибо за внимание и удачи вам!

habr.com

Три перспективных направления в IT для создания стартапа | Карьера и свой бизнес

Интернет вещей

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

Одновременно с появлением новинки Apple один из ведущих в мире акселераторов технологических проектов Techstars.com создал отдельную акселерационную программу для стартапов, работающих в сфере «интернета вещей», — Connected Devices (связанные устройства).

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

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

Информатика здоровья

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

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

Стартапы по быстрому реагированию и использованию устройств медицинской сигнализации, такие как американский проект Amulyte — выпускник летнего набора 2013 года акселератора Y Combinator или один из победителей конкурса стартапов Forbes 2012 года «Кнопка Жизни», — лишь начало пути, на который встала индустрия. Но настоящую революцию произведет система, объединяющая данные сенсоров и датчиков состояния организма с генетической информацией. Приложения дадут возможность влиять на физическое состояние, рекомендуя соответствующий образ жизни, предписывая определенный пищевой рацион, добавки и медикаменты.

Для иллюстрации тренда достаточно сказать, что информатику здоровья назвали новым мегатрендом Founders Fund Шона Паркера (создатель Napster и инвестор Facebook и PayPal) SV Angel Рона Конвея (инвестор Google и Twitter) и уже делают первые вложения в подобные проекты.

Умное потребление — совместное потребление

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

Теперь очередь за проектами, которые позволяют совместно не приобретать, а пользоваться, обмениваться, сдавать и брать в аренду. Сервисы по обмену и совместному использованию абсолютно всего (craigslist.org), аутсорсингу небольших заданий (TaskRabbit), сдаче/аренде машин (zipcar.com) давно привлекают внимание. Появляются все новые идеи: сервисы по размещению в других городах (airbnb.com), по сдаче/аренде машин (flightcar.com) или мобильные приложения, позволяющие брать вещи напрокат и сдавать собственные (usarium.com). Революция в социально-экономической модели потребления начинает набирать обороты.

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

www.forbes.ru

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *