Рубрика «управление проектами» - 130

На конференции Monitorama Пит Чеслок из Threat Stack провел параллель между историей строительства шведского корабля «Васа» и провальными проектами по разработке. Делимся с вами отрывком его выступления.

image

Корабль «Васа» должен был стать главным боевым кораблем шведского флота, но затонул с порывом ветра при первом же выходе из гавани в 1628 году, 53 члена экипажа погибли. Выживший капитан был немедленно отправлен в тюрьму: на он допросе клялся, что пушки были надежно закреплены, и экипаж был трезв. После расследования никто не был наказан или признан виновным, и инцидент был классифицирован как «Воля Божья». Почему затонул корабль и причем тут управление проектами?
Читать полностью »

Лета как будто и не было: кажется, буквально вчера все взахлеб обсуждали июньскую презентацию с WWDC, на которой представители Apple рассказали общественности об iOS 11, и вот уже считанные недели отделяют нас от публичного релиза. А значит, пришло время освежить в памяти все, что было сказано о новом девайсе, и морально подготовиться к неизбежным переменам, которые ждут всех, кто имеет дело с мобильными приложениями. И это касается не только разработчиков. В новой версии было значительно переработан App Store, а значит достанется и маркетологам, и контент-менеджерам, и дизайнерам — измененная среда продвижения задает новые правила и приоритеты, тем самым заставляя меняться и продукт.

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

App Store на iOS 11: каким он будет и что это значит - 1

Читать полностью »

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

Читать полностью »

Геймеры по жизни: что мы знаем о поколении Y - 1

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

Читать полностью »

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

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

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

Ненаучная революция: как не разориться на фейковых инновациях - 1Читать полностью »

Акселератор основанный на CrowdSourcing - 1

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

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

Правда поиск таких людей, не всегда происходит эффективно, поскольку в целом инфраструктуры (она разрознена) для этого отсутствует. По этой причине в IT-сфере (как сообщества с которого всё начинается) уже существуют проекты, улучшающие эту область, например:
Cofounder.ru: дэйтинг-сервис для стартаперов
Онлайн-сервис поиска сотрудников и партнеров для стартапов от ФРИИ

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

В следствии этого, а так же с учетом тенденцийЧитать полностью »

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

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

О(n2): Совещание равноправных участников. n человек обсуждают вопрос, причем для достижения взаимопонимания, каждому участнику нужно пообщаться с каждым. Всего будет осуществлено n*(n-1)/2 социальных взаимодействий (эквивалентно задаче подсчета числа рукопожатий в группе из n человек), т.е сложность алгоритма О(n2). Казалось бы, за счет того, что общение одновременно могут осуществлять n/2 пар людей, оценка по времени – О(n), однако на реальных совещаниях в один момент времени говорит только один человек, поэтому оценка для худшего случая — О(n2). Если время взаимодействия – 5 минут и для достижения полного взаимопонимания в группе требуется две итерации, то совещание трех человек продлиться 30 минут, четырех – час, пятерым потребуется 1 час 40 минут для нахождения общего решения (что подозрительно похоже на правду). Если же число итераций зависит от числа участников, мы получаем еще более печальные оценки.

Но не все так плохо!Читать полностью »

С частью 1 можно ознакомиться, перейдя по ссылке
С частью 2 можно ознакомиться, перейдя по ссылке

Использование спецификаций требований в управлении проектом

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

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

Но, естественно есть погрешности и процедура – процедуре рознь, поэтому, для более точного расчета можно использовать коэффициенты сложности для реализуемых объектов. Например, «сложная форма» — 1,5; «обычная форма» — 1; «простая форма» — 0,5. Для каждого типа элемента подбираем свою линейку значений коэффициентов. Полученные таким образом данные можно занести в электронную таблицу и сбить итоговые затраты в человекоднях или человекочасах (как Вам удобнее) по подсистемам и проекту в целом.
Читать полностью »

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

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

С частью 1 можно ознакомиться, перейдя по ссылке

Рекомендации по проектированию спецификаций требований с примерами

То, о чем не говорят, каждый понимает по-своему

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

Готовим читателей к знакомству со спецификациями

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

Пример обзора документа:
О качестве требований в ИТ проектах, на чистоту (с позиции команды разработки). Часть 2 - 1

Для лучшего восприятия контекста разрабатываемой системы, помимо разделов, отобранных нами в структуру документа — как обязательные, я стараюсь включить в текст информацию о целях, которые должны быть достигнуты в результате разработки целевого продукта или его составного модуля. Разработчики все-таки должны осознавать, чего же желает заказчик получить на выходе проекта. Для описания этого раздела подойдут формализованные Потребности заказчика. Похожий раздел есть в большинстве стандартов, например в ГОСТ-34.602-89 [4] он называется «назначение и цели создания (развития) системы».
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js