Рубрика «сроки»

Неразрешимые проблемы разработки - 1

Сроки

В разработке ПО существует неразрешимое противоречие — это оценка сроков.

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

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

  • новая функциональность нетипична
  • есть зависимости на другие команды
  • будет задействована новая технология
  • ТЗ надо сильно уточнять
  • надо разобраться в логике легаси-кода

Часто, для того, чтобы точно оценить сроки, нужно, собственно, сделать половину работы. Чем точнее надо оценить сроки, тем больше надо на это затратить времени, что приводит к суммарному увеличению time-to-market, причем все равно без гарантий.

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

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

Я решил выкинуть всё ожидание и рассказывать о результатах собеседования настолько рано, насколько это возможно — в конце встречи. Эксперимент удался, делюсь.

Спасибо за собеседование, мы ответим о нашем решении… сейчас - 1

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

Подсказка: явно не ваших пользователей.

Поднимите руку те, чья компания провозгласила «Клиентоориентированность» как одну из своих корпоративных ценностей. Для тех из вас, кто читает этот текст на Хабре и не видит аудиторию: почти весь зал поднял руку, кроме пары человек сзади.

Они работают в Oracle.

Удовлетворенность клиентов является одной из корпоративных ценностей компании Oracle. Но корпоративные ценности — они как абонемент в спортзал — недостаточно их просто иметь.

Одержимость клиентами — полезная вещь, но есть ещё одна вещь, которой одержимы многие компании — это сроки. Дедлайны — это хорошо. «Будет готово, когда я закончу» может быть отличной (или даже рекомендованной) стратегией для двух человек работающих над одним приложением. Но когда вы работаете в компании с более чем двумя сотнями сотрудников, вам требуется некоторое понимание того, что происходит; примерное представление о том, когда ваши пользователи смогут использовать ваши новые свистелки и перделки.

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

Дедлайны нужны в первую очередь не клиентам, а менеджменту.Читать полностью »

«Работа заполняет время, отпущенное на неё».
Закон Паркинсона

Если ты не британский чиновник образца 1958 года, не надо следовать этому закону. Никакая работа не обязана занимать всё отведённое на неё время.
Читать полностью »

Автор этого материала делится способом оценки времени, которое будет затрачено на переписывание уже внедренного проекта.

Цена изменений: во сколько на самом деле обойдется переработка кода - 1

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

Модель оценки объема работ

Вы можете свести в один список все фичи своего приложения, а после оценить этапы и приблизительное время их переработки. Большинство именно так и поступает перед тем, как приступить к работе. Но почему тогда на практике выходит, что подобные проекты занимают в 4, 8 или даже 10 раз больше времени, чем разработчики заложили на старте?

Читайте также

Публикация о временных затратах на написание программного кода, которая пригодится при оценке объема работ: «Правило 10:1 в программировании и писательстве»

Есть три ключевых фактора, которые существенно растягивают процесс. И обычно при оценке затрат их игнорируют. Речь идет о
1) необходимости наверстать разницу между уровнями текущего и нового приложений,
2) объеме непредусмотренных изменений,
3) улучшениях, которые придется сделать, чтобы пользователи захотели перейти на новое приложение.

Цена изменений: во сколько на самом деле обойдется переработка кода - 2

Сокращение разницы

Первый фактор — новому приложению необходимо догнать текущее.Читать полностью »

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

Правило 10:1 в программировании и писательстве - 1

Закон Хофштадтера: Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.
— Дуглас Хофштадтер, Гёдель, Эшер, Бах

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

Изучая свои книги

Обе свои книги, Привет, стартап и Terraform: запускаем и работаем, я написал в среде для создания книг Atlas, которая предусматривает управление всем контентом с помощью Git. Это означает, что каждая строчка текста, каждая правка и каждое изменение были зафиксированы в коммит-логе Git.

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

Начнем с моей первой книги Привет, стартап. В ней 602 страницы и примерно 190 тыс. слов. Я запустил cloc в git-репозитории Hello, Startup и получил следующие результатыЧитать полностью »

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

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

Умение говорить Нет — это способность человека признавать реальные ограничения и наличие мужества признать их и сообщить клиенту об их влиянии. Я буду судить с точки зрения ИТ компании которая работать на б2б рынке.

Когда возникают ситуации когда нам нужно говорить нет, и как это сделать?
Читать полностью »

image

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

Итак, давайте структурируем договор и взаимодействия с клиентом:
Читать полностью »

Несколько советов для тех, кто перепоручает задачи, работает с подрядчиками, фрилансерами и прочими исполнителями

Привет. Я Саша и я руковожу студией Flyphant, которая занимается разработкой мобильных приложений, сайтов и видео монтажом и анимацией (в английском языке это бы звучало как Motion graphics).

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

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

Всем привет,

Выяснилось, что я все таки спринтер, а не стаер, и писать длинные умные тексты у меня не очень получается. Нет времени, не хватает усидчивости. Поэтому перейду ка я на систему очень четких и явных списков того, как мы решаем конкретные проблемы.

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

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


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