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

— Какое отношение имеет морская свинка к морю?
— Примерно такое же, как утконос к проектированию дирижаблей.

Введение.

Я имею обыкновение во время прогулок прокручивать информацию из нескольких источников, сопоставляя куски. Одна из любопытных находок – почти полное соответствие статистических наблюдений Демарко и Листера в «Peopleware» и теоретических выкладок Голдратта в «Критической цепи».

Осенью 2011 я крутил в голове:
[1] «Стоя на плечах гигантов» Эли М. Голдратт © Eliyahu M. Goldratt, 2008
[2] «Производственный менеджмент: управление потоком» Одед Коуэн, Елена Федурко
[3] «История одной доски» (http://cartmendum.livejournal.com/tag/theboard).

Далее хотелось бы написать: «Как вдруг…», — но это будет неправдой. Это случилось не вдруг. Мне понадобилось пару недель, но, в конце концов, в голове сложилась достаточно цельная картинка.

За что именно я зацепился:

  • Таичи Оно (Öno Taiichi) не понимал, почему его система работает.
  • Существует несколько разных типов производственных потоков – V, A, T, I. Каждый тип потока ставит особые задачи.
  • Неудачи внедрения доски Максима Дорофеева в некоторых подразделениях
  • Ряд компаний не смог внедрить систему Тойота, несмотря на все приложенные усилия.
  • Система Тойота и система Форда основывается на одинаковых принципах, но прикладные решения ограничены определенными типами производства.

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

Привет!

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

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

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

Кому интересно — добро пожаловать под кат!
Читать полностью »

Привет, читатели!

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

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

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

Вступление

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

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

Передаём проект: howtoМного в этом мире сказано, что код надо писать так, чтобы его было легко поддерживать любому другому разработчику, и чтобы проект мог быть передан на поддержку другим людям в любой момент. Но каково это – передавать проект, с которым прожил несколько лет, в совсем другие руки? Кем окажется для проекта его новый руководитель – вторым отцом или злым отчимом (уважаемые читательницы, я помню о вашем существовании, но вы в меньшинстве)? Будет наше детище развиваться и набирать сил, или умрёт, уступив место чему-нибудь куда менее красивому, явно не столь качественному (мы-то понимаем, кто здесь самый крутой профессионал) и совсем чужому? Для тех, кого действительно волнует его будущее, и написана данная статья. Замечу, что в ABBYY я проработал в нескольких проектах, оставлял их по разным причинам, большинство из проектов – задачи без чёткого решения (распознавание, поиск разных неформально описанных объектов и т.п.). Читать полностью »

Доброго времени, читатели.

Хочу поделиться наблюдениями возникшими в процессе проведения трека «Usability Engineering & Ubiquitous Computing on mobile devices» который проводился в рамках совместной российско-немецкой студенческой школы JASS-2012 о которой уже писали на хабре. Однако, в отличие от предыдущего поста я буду описывать школу глазами организатора.

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

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

Инициация проектов

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

Поняв свою оплошность мы приняли решение не следовать начальным планам — если уж быть agile, то быть agile во всем, и начали работу над Читать полностью »

ISO 9001 в ИТ компании
Сейчас редко найдешь среднюю или большую ИТ компанию, не имеющую ISO 9001 сертификата.
Тем не менее, я считаю, что в ближайшей перспективе ISO 9001 умрет для ИТ мира. Почему?
Попытаюсь обосновать.
Читать полностью »

Если вы живёте в Москве и хотите познакомиться лично с понравившейся девушкой из call-центра «Билайна», вас может ждать сюрприз. Ехать на свидание придётся, например, в Тверь или в другой соседний город.

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

Облако контакт центров «Билайна»: что бывает при пиковой нагрузкеЧитать полностью »

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

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


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