Всегда ли просто определить приоритеты в задачах крупного проекта? А если в приоритете находятся пять срочных задач? Десять?
Опытные менеджеры проектов и собственники продуктов знают, что одной интуицией здесь не обойтись. Для того, чтобы не подвести команду и уложиться в сроки, сегодня на помощь менеджерам приходят полезные методологии определения приоритетов, а также современные инструменты, которые помогают визуализировать данные и ничего не упустить в своих рабочих процессах.
Чтобы выполнить большой и важный труд, необходимы две вещи:
ясный план и ограниченное время.
Элберт Хаббард
И вот заказчик и исполнитель ударили по рукам, решив, что именно они будут производить, определив примерные сроки и стоимость. Начинается второй этап производства программного продукта.
Наступает момент, когда в водоворот процессов активно втягивается руководитель проекта. Нет, он и до этого мог участвовать в мероприятиях. Например, связанных с оценкой трудоемкости, определения сроков и т.п., но именно сейчас он получает возможность сполна проявить все свое мастерство планирования и управления.
На текущем шаге пока еще не ясны детальные требования к целевой системе, их как раз и предстоит выявить в рамках текущей активности, поэтому планирование удобно разделить на части. График работ по формированию проектного решения разрабатываемой системы уже можно детально проработать, а вот план по его реализации и внедрению можно будет детализировать чуть позже по итогам завершения второго этапа.
Первое, что руководитель проекта должен включить в план — это свои собственные работы. С протяженностью этой трассы на диаграмме Ганта вряд ли может конкурировать еще какая-то линия. Под ней располагаются, прерывающиеся в некоторых местах, колеи сотрудников проектно-аналитического цеха.
Занимаясь масштабными проектами автоматизации и создавая новые информационные системы, мы каждый раз сталкивались с необходимостью реализации подсистемы ведения справочников, классификаторов, реестров и других подобных объектов, составляющих нормативно-справочную информацию (НСИ) заказчика. За 15 лет работы в ЛАНИТ с системами управления НСИ жизнь подкидывала нам клиентов с самыми различными требованиями. И, конечно, на этих проектах возникали разные ситуации. Я расскажу о нескольких поучительных историях, которые с нами произошли. В статье вы найдете примеры, которые будут полезны многим, кто занимается разработкой программного обеспечения. Ну, а тем, кто работает непосредственно с НСИ, будет еще интереснее – своя рубашка ближе к телу.
За иллюстрации отдельное спасибо замечательному художнику Васе Ложкину.
Когда существуют варианты – важно не ошибиться и изучить все детали и возможности, чтобы остановиться на лучшем. Выбирать между методами управления разработкой не всегда просто, особенно если это Scrum и Kanban.
По просьбам трудящихся представляем новый материал из цикла статей об интеграции разнообразных IT-систем в инфраструктуре заказчика. На этот раз более подробно остановимся на таком симбиозе, как система мониторинга и ITSM-система.
Что представляют из себя эти системы по отдельности рассказывать можно долго. Правильно настроенная и работающая система мониторинга помогает избежать многих бед или предотвратить их, а ITSM-система позволяет управлять IT-процессами и регистрировать события, случающиеся в инфраструктуре. Мы не будем углубляться в тонкости работы данных систем по отдельности, а изучим, как соединить данные системы на благо заказчика в целом и сервисной компании, обслуживающей IT-инфраструктуру, в частности.
Читать полностью »
Решил кратко сформулировать 3 причины, по которым embedded-разработчикам полезны инструменты статического анализа кода программ.
Читать полностью »
Из хаоса каким-то образом рождается порядок.
Некоторые об этом узнают из газет со значительным опозданием, а некоторые по горькому опыту на месте и в процессе создания этого порядка.
Михаил Булгаков.
Просматривая статьи, посвященные той или иной теме, связанной с созданием программного обеспечения, часто наблюдаю, вот какую картину: узкая тема раскрыта интересно и профессионально, но вот когда задеваются нюансы на стыке, по ту сторону от основного вопроса, чувствуются рассогласованность и провалы в общем понимании процесса производства информационных систем. Разрываются причинно-следственные связи. Иногда, непонимание внешнего окружения обсуждаемого вопроса, вносит искажения в основную тему, ну или по крайней мере, затушевывает некоторые важные моменты, достойные внимания. Когда же вступаешь с автором в полемику, становится очевидным, что для него вопросы, выходящие за рамки его наблюдений и опыта, абсолютно неважны. Он просто упомянул всуе сопредельную тему, а дальше, как говорится, уже не его проблемы. Второй нюанс, на котором я хочу заострить внимание – пренебрежение масштабами замысла. Ведь то, что хорошо для реализации малых проектов, смерть для больших и наоборот. Этот факт часто попросту сбрасывается авторами со счетов. А в результате идут баталии с критиками решения, в которых каждый как бы и прав, но только с точки зрения своей отдельностоящей колокольни. Сами же точки зрения никак не обозначаются сторонами дискуссии, а потому никак не учитываются.
Исходя из всего вышесказанного, мне показалось, что будет весьма пользительно собрать и описать структуру процесса производства программных продуктов (ну хотя бы основных вариантов), при этом не вдаваясь глубоко в специфические детали, а фабулу изложить в формате, предельно доступном для широкого круга лиц. Естественно данная публикация – это лишь мой взгляд на предмет.
Читать полностью »
Про обратную связь, которая вызывает желание убивать
Привет, я бизнес-аналитик и частенько наблюдаю за менеджерами, которых все ненавидят. Сегодня я расскажу, как с максимальной эффективностью конвертировать сотрудников во врагов.
У программистов, как и у всех людей, есть фобии. Кто-то боится маньяков, кто-то — утки, которая следит за человеком, кто-то впадает в панику при нарушении привычного распорядка дня, кого-то начинает штырить от внезапно пропавшей связи в смартфоне.
Все это, если можно так сказать, общечеловеческие фобии, присущие целым поколениям, странам и континентам. Но есть и чисто профессиональные фобии, которые вряд ли будут понятны представителям других профессий.
Фобии — это зло, как в жизни, так и в работе. Потому что предмет страха — выдуманный, а сам страх — настоящий. И последствия страхов вполне реальные.
В этой статье — истории реальных программистов и их профессиональных фобий, которые мешали им жить и работать в свое удовольствие. Люди реальные, имена вымышленные.
Читать полностью »
Хорошо или плохо, когда яблоком раздора становится не сама вакансия, а право на её существование? Анонс завтрашнего московского турнира соискателей вакансий Software Engineering Manager вдруг стал «местом для дискуссий».
И дискуссий таких острых, что стало ясно — бросать тему нельзя. Впрочем, мы и так будем лезть под капот «кроссоверовской» иерархии должностей, разбирать завершённые проекты и повседневные обязанности сотрудников. Но лучше один раз увидеть, а ещё лучше — принять участие, чем сто раз услышать. Поэтому мы предлагаем читателям челлендж: те из вас, кто нас видел или увидит — расскажите о нас правду на страницах этого блога без купюр.
Читать полностью »
