Всем привет! Меня зовут Константин Замков. Я главный менеджер в компании «СИБИНТЕК», сертифицированный специалист по управлению проектами PMI PMP, управлению портфелями проектов PMI PfMP и Scrum-мастер PSM-I. В своей работе я управляю сложными комплексными ИТ-проектами и регулярно занимаюсь разработкой и актуализацией календарных планов. В этой статье хочу поделиться практическим подходом, который сформировался у меня за годы работы.
Рубрика «сроки»
Практика календарного планирования ИТ-проекта
2026-04-11 в 6:16, admin, рубрики: календарный план, критический путь, менеджмент, планирование, проект, срокиНеразрешимые проблемы разработки
2023-07-20 в 6:20, admin, рубрики: KPI, Программирование, Разработка веб-сайтов, сроки, управление персоналом, Управление продуктом, управление проектами
Сроки
В разработке ПО существует неразрешимое противоречие — это оценка сроков.
С одной стороны, бизнесу надо знать, сколько займёт разработка фичи, причем как можно точнее. И это понятно — ведь надо как-то принимать решения, чтобы сравнить предполагаемые доходы и расходы и достать деньги в нужном количестве.
С другой стороны, разработка порою в душе не е... вообще не знает, сколько надо времени, особенно если
- новая функциональность нетипична
- есть зависимости на другие команды
- будет задействована новая технология
- ТЗ надо сильно уточнять
- надо разобраться в логике легаси-кода
Часто, для того, чтобы точно оценить сроки, нужно, собственно, сделать половину работы. Чем точнее надо оценить сроки, тем больше надо на это затратить времени, что приводит к суммарному увеличению time-to-market, причем все равно без гарантий.
Спасибо за собеседование, мы ответим о нашем решении… сейчас
2020-06-18 в 15:25, admin, рубрики: dodo mobile, Dodo Pizza Engineering, iOS, Блог компании Dodo Pizza Engineering, Карьера в IT-индустрии, мобильная разработка, обратная связь, резюме, собеседование, собеседования, сроки, техническое интервью, техническое собеседование, управление персоналом, фидбекКогда я сам был кандидатом и ходил по собеседованиям, больше всего меня бесило ожидание обратной связи: долго, скучно, нельзя обсудить решение. Оказавшись на месте интервьюера, я заметил, что чаще всего все нужные выводы делаются буквально за 5 минут после встречи. Остальное время — бесполезное растягивание процесса и бюрократия. Главная причина не отвечать сразу понятна — эмоционально сложно обсуждать решение с кандидатом, ведь часто нужно отказывать. В итоге программисты увиливают и передают эту задачу HR.
Я решил выкинуть всё ожидание и рассказывать о результатах собеседования настолько рано, насколько это возможно — в конце встречи. Эксперимент удался, делюсь.

Кого вы пытаетесь впечатлить своими дедлайнами?
2020-01-15 в 3:40, admin, рубрики: agile, deadline, deadlines, дедлайны, Программирование, спринты, сроки, управление проектами, управление разработкойПодсказка: явно не ваших пользователей.
Поднимите руку те, чья компания провозгласила «Клиентоориентированность» как одну из своих корпоративных ценностей. Для тех из вас, кто читает этот текст на Хабре и не видит аудиторию: почти весь зал поднял руку, кроме пары человек сзади.
Они работают в Oracle.
Удовлетворенность клиентов является одной из корпоративных ценностей компании Oracle. Но корпоративные ценности — они как абонемент в спортзал — недостаточно их просто иметь.
Одержимость клиентами — полезная вещь, но есть ещё одна вещь, которой одержимы многие компании — это сроки. Дедлайны — это хорошо. «Будет готово, когда я закончу» может быть отличной (или даже рекомендованной) стратегией для двух человек работающих над одним приложением. Но когда вы работаете в компании с более чем двумя сотнями сотрудников, вам требуется некоторое понимание того, что происходит; примерное представление о том, когда ваши пользователи смогут использовать ваши новые свистелки и перделки.
Смею утверждать, что жестко установленные сроки — это плохие сроки, и если у вашей компании такие есть, возможно следует пойти еще дальше, и убрать пункт об «клиентоориентированности» из списка корпоративных ценностей. Потому что, хотите верьте, хотите нет, пользователям плевать на заваленные спринты.
Дедлайны нужны в первую очередь не клиентам, а менеджменту.Читать полностью »
Закон Паркинсона и как его нарушить
2019-07-30 в 15:10, admin, рубрики: менеджмент, сроки, управление людьми, Управление продуктом, управление проектами, управление разработкой, Читальный зал«Работа заполняет время, отпущенное на неё».
Закон Паркинсона
Если ты не британский чиновник образца 1958 года, не надо следовать этому закону. Никакая работа не обязана занимать всё отведённое на неё время.
Читать полностью »
Цена изменений: во сколько на самом деле обойдется переработка кода
2018-12-26 в 11:23, admin, рубрики: Wirex, Блог компании Wirex, дедлайн, оценка времени, оценка стоимости проекта, оценка трудозатрат, Программирование, сроки, Статистика в IT, управление разработкойАвтор этого материала делится способом оценки времени, которое будет затрачено на переписывание уже внедренного проекта.

По мере разрастания кода работать с ним становится все труднее. Годы разработки и отлавливания багов приводят к желанию перечеркнуть все и начать с чистого листа. Действительно, очень заманчива мысль о том, чтобы оставить ошибки в прошлом, вооружиться новыми технологиями и на этот раз все сделать правильно. Однако перед прыжком в бездну я все же предлагаю внимательнее присмотреться к реальной стоимости этого шага.
Модель оценки объема работ
Вы можете свести в один список все фичи своего приложения, а после оценить этапы и приблизительное время их переработки. Большинство именно так и поступает перед тем, как приступить к работе. Но почему тогда на практике выходит, что подобные проекты занимают в 4, 8 или даже 10 раз больше времени, чем разработчики заложили на старте?
Публикация о временных затратах на написание программного кода, которая пригодится при оценке объема работ: «Правило 10:1 в программировании и писательстве»
Есть три ключевых фактора, которые существенно растягивают процесс. И обычно при оценке затрат их игнорируют. Речь идет о
1) необходимости наверстать разницу между уровнями текущего и нового приложений,
2) объеме непредусмотренных изменений,
3) улучшениях, которые придется сделать, чтобы пользователи захотели перейти на новое приложение.

Сокращение разницы
Первый фактор — новому приложению необходимо догнать текущее.Читать полностью »
Правило 10:1 в программировании и писательстве
2018-08-29 в 10:45, admin, рубрики: atlas, express.js, Git, jquery, mysql, terraform, terratest, Wirex, Блог компании Wirex, дедлайн, Программирование, Системы управления версиями, сроки, Статистика в ITВ этой статье автор анализирует количество времени, которое тратится на написание книг или программного кода, и приходит к интересной закономерности. Ее можно применять для планирования сроков работы над проектами.

Закон Хофштадтера: Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.
— Дуглас Хофштадтер, Гёдель, Эшер, Бах
У написания прозы и кода есть много общего. Но самое заметное сходство, вероятно, заключается в том, что ни писатели, ни программисты не могут закончить свою работу вовремя. Писатели славятся отъявленной привычкой срывать сроки. Программисты заслужили репутацию людей, чьи результаты всегда серьезно отличаются от первоначальных расчетов. Возникает вопрос: почему?
Сегодня у меня появилась идея, как можно на него ответить. И мои находки меня поразили.
Изучая свои книги
Обе свои книги, Привет, стартап и Terraform: запускаем и работаем, я написал в среде для создания книг Atlas, которая предусматривает управление всем контентом с помощью Git. Это означает, что каждая строчка текста, каждая правка и каждое изменение были зафиксированы в коммит-логе Git.
Проверим, сколько же усилий было затрачено на написание двух книг.
Привет, стартап
Начнем с моей первой книги Привет, стартап. В ней 602 страницы и примерно 190 тыс. слов. Я запустил cloc в git-репозитории Hello, Startup и получил следующие результатыЧитать полностью »
Умение говорить Нет — ключевой навык менеджера. Обусловленное нет
2015-12-18 в 7:11, admin, рубрики: менеджмент, сроки, Управление продажами, Управление продуктом, управление проектамиЯ перфекционист и был воспитан в духе «клиент всегда прав». Я всегда упивался своим качеством выполнения работы, тем что людям нравилось что я делаю и ко мне часто обращались в сложных ситуациях. Но каждый день на работе был днем когда я ощущал себя плохо. Любая ошибка, задержка сроков, неудовлетворение клиента, жалоба, отражались на моей работоспособности, мне хотелось включить ютюб, полазить на пикабу и отгородится от мира, потому что я такой плохой, и не самый лучший в мире.
Это был я в молодости, но со временем, приобретая тяжелый опыт реальных проектов, не идеальных заказчиков и реалий финансовой жизни я научился одному из главных качеств менеджера, по моему мнению, умению говорить Нет. Позвольте мне поделится некоторыми советами в этой области.
Умение говорить Нет — это способность человека признавать реальные ограничения и наличие мужества признать их и сообщить клиенту об их влиянии. Я буду судить с точки зрения ИТ компании которая работать на б2б рынке.
Когда возникают ситуации когда нам нужно говорить нет, и как это сделать?
Читать полностью »
Как защитить свои интересы при оказании услуг на примере разработки интернет-проектов веб-студии
2015-06-29 в 21:59, admin, рубрики: акты, договор, документооборот, Законодательство и IT-бизнес, пени, платежи, сроки, управление проектами, финансы в IT, этапы 
Давайте начнем с тезиса: Выполняйте работу качественно и в срок.
Если работа выполнена плохо и прошли все сроки, то последующие советы только частично помогут агонии минимизировать ваши риски. Если проект выполнен согласно договору, то следующие рекомендации позволят вам чувствовать себя уверенно в переговорах и доказать свою правоту в арбитражном или третейском суде.
Итак, давайте структурируем договор и взаимодействия с клиентом:
Читать полностью »
Подрядчики: как с ними работать
2015-06-09 в 18:39, admin, рубрики: оплата, подрядчики, сроки, управление проектами, фрилансНесколько советов для тех, кто перепоручает задачи, работает с подрядчиками, фрилансерами и прочими исполнителями
Привет. Я Саша и я руковожу студией Flyphant, которая занимается разработкой мобильных приложений, сайтов и видео монтажом и анимацией (в английском языке это бы звучало как Motion graphics).
Мне часто приходится взаимодействовать с подрядчиками в сфере дизайна, копирайта, работы со звуком, верстки, программирования и прочих смежных дисциплин. В этом плане у меня уже набрался небольшой опыт, который позволяет добиваться ожидаемого результата в срок.
Ниже представлены несколько правил, которых я стараюсь (не всегда получается, но я стараюсь ☺) придерживаться при работе с подрядчиками, в результате чего работой (и процессом, и результатом) довольны все.
Читать полностью »
