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

Предыдущая статья цикла: Ретроспектива технологических стартапов. Z3 — первый релейный компьютер

Ретроспектива технологических стартапов. Как это было в 90-х и чуть раньше - 1

В этой статье продолжаю ретроспективу стартапов. Перенесёмся из Германии Второй Мировой в молодую Россию начала 90-х прошлого столетия. В этот раз будет много примеров о том как это происходило в Зеленограде и попытка ответить на вопрос: “Как и почему в то время бизнесы по производству электроники вырастали с нуля как на дрожжах”.
Но для начала заглянем ненадолго в эпоху заката звезды СССР.

Для чего всё это?

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

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

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

Выбирать такие задачи помогают методы приоритезации и здравый смысл.

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

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

Кажущаяся простота

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

Риск нужно:

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

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

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

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

«Всё — яд, всё — лекарство; то и другое определяет доза.»
Парацельс

Мифы и легенды Agile — oт фараонов до наших дней - 1

Принято отсчитывать историю Agile от февраля 2001 года, когда появился на свет довольно странный документ — Agile Manifesto. По большому счёту текст документа скомпонован из философских очевидностей (например, «простота — искусство не делать лишней работы») и спорных утверждений (например, «лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды»). Но этот документ странен не столько своим содержанием (мало ли что может прийти в голову на лыжном курорте), сколько эпичностью последовавших изменений в отрасли разработки программного обеспечения. В кратчайшее время появилось множество методик, реализующих методологию «гибкой» разработки, которые торжественным маршем пошли по миру, захватывая умы Исполнителей и кошельки Заказчиков. Адептами этот движ преподносится как некая волшебная пилюля, решающая всё. Дошло до того, что благородному дону честному программисту уже стало неприличным признаться в причастности к разработке ПО по традиционной ориентации методологии. Попробуем же разобраться в причинах и следствиях явления, на примере Scrum-а, как наиболее распространённого проявления Agile.
Читать полностью »

Для корабля, не имеющего пристани, ни один ветер не бывает попутным. Сенека

Несколько дней назад стало известно о том, что компания SmugMug, приобретшая в апреле сего года фотохостинг Flickr, объявила об отмене 1 ТБ дискового пространства для бесплатных пользователей. По новым условиям им придется довольствоваться 1000 фотографий, ограничения вступают в силу с января 2019 г. Обладатели платных аккаунтов будут иметь неограниченный объем облачного хранилища за те же 50 долл. США в год.

RIP

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

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

Есть в истории «Параграфа» — первого стартапа из России, покорившего мир — один парадокс.

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

Основателю книгу Степану Пачикову до сих пор припоминают работу Newton, далекую от совершенства. Ну и когда я рассказал на «Хабре» о том, что пишу о «Параграфе» книгу, эта тема конечно тут же всплыла.

Как может передовая разработка так разочаровать пользователей? Почему на самом деле Newton не взлетел? И, главное, виновата ли на самом деле команда российских ученых в его провале?

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

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

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

Так что я решил такой каталог ошибок составить. И вот что получилось. Читать полностью »

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

Участники Saint TeamLead Conf назвали доклад Александра Зизы одним из лучших вероятно потому, что от навыков коммуникации тимлида зависит многое, а развиты они, как правило, не очень хорошо.

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

Коммуникации как performance-зона работы тимлида - 1

О спикере: Александр Зиза (Aletheia Business) разработчик программы развития управленческого мышления, консультант по психологии трансформационных изменений. Имеет образование физика, финансового директора и психолога, и разнообразный бэкграунд в IT, включая разработку железа, реализацию крупных IT-проектов, формирование команд.
Читать полностью »

За время своей карьеры я поработал с разными legacy-проектами, каждый из которых страдал от тех или иных изъянов.

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

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

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

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

2_fview_gameplay

История, которую я расскажу, началась 13 лет назад на уроке информатики. Мы с друзьями-семиклассниками решили все задачи на Паскале и весело играли в первый Quake. Наша учительница увидела это, подошла ко мне и сказала всего одну фразу, которая перекосила мою картину мира: «Если ты хочешь играть в игры на уроке, пиши их сам». С тех пор я эпизодически делаю игры. Одна из них — футбольный симулятор, о котором и пойдёт речь.

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

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


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