2022 год научил нас быстро менять приоритеты для оперативного реагирования на внешние факторы. В наших целях была зафиксирована ключевая задача по отказу от софта вендора в пользу собственных решений, разработанных на основе микросервисной архитектуры. Стоял вполне комфортный срок: полностью завершить переход до конца года, и команды планомерно шли к этой цели, наряду с разработкой менее масштабных, но тоже важных фич. Но в связи со вполне реальными рисками преждевременного ухода вендора из РФ сроки доработок сократились с полугода до одного месяца (почти как в известной шуткеЧитать полностью »
Рубрика «дедлайн»
Как девять женщин могут родить ребёнка за месяц
2023-02-10 в 8:04, admin, рубрики: Анализ и проектирование систем, Блог компании ДомКлик, дедлайн, проектирование, разработка, управление персоналом, управление проектами, управление разработкойКак программировать если совсем не хочется? План спасения на случай перегорания или дедлайна
2020-11-26 в 5:39, admin, рубрики: gtd, апатия, дедлайн, депрессия, здоровье, Лайфхаки для гиков, мозг, продуктивность работы, прокрастинация
Никакой воды в этой статье, только описание конкретного плана действий в случае если вы перегорели, у вас дедлайн, прокрастинация, депрессия, а также методики и советы помогающие привести этот план в действие.
Цена изменений: во сколько на самом деле обойдется переработка кода
2018-12-26 в 11:23, admin, рубрики: Wirex, Блог компании Wirex, дедлайн, оценка времени, оценка стоимости проекта, оценка трудозатрат, Программирование, сроки, Статистика в IT, управление разработкойАвтор этого материала делится способом оценки времени, которое будет затрачено на переписывание уже внедренного проекта.
По мере разрастания кода работать с ним становится все труднее. Годы разработки и отлавливания багов приводят к желанию перечеркнуть все и начать с чистого листа. Действительно, очень заманчива мысль о том, чтобы оставить ошибки в прошлом, вооружиться новыми технологиями и на этот раз все сделать правильно. Однако перед прыжком в бездну я все же предлагаю внимательнее присмотреться к реальной стоимости этого шага.
Модель оценки объема работ
Вы можете свести в один список все фичи своего приложения, а после оценить этапы и приблизительное время их переработки. Большинство именно так и поступает перед тем, как приступить к работе. Но почему тогда на практике выходит, что подобные проекты занимают в 4, 8 или даже 10 раз больше времени, чем разработчики заложили на старте?
Читайте также
Публикация о временных затратах на написание программного кода, которая пригодится при оценке объема работ: «Правило 10:1 в программировании и писательстве»
Есть три ключевых фактора, которые существенно растягивают процесс. И обычно при оценке затрат их игнорируют. Речь идет о
1) необходимости наверстать разницу между уровнями текущего и нового приложений,
2) объеме непредусмотренных изменений,
3) улучшениях, которые придется сделать, чтобы пользователи захотели перейти на новое приложение.
Сокращение разницы
Первый фактор — новому приложению необходимо догнать текущее.Читать полностью »
Приходится выбирать, какой софт вам нужен: написанный вовремя или качественный
2018-09-27 в 10:03, admin, рубрики: Alconost, software, алконост, Блог компании Alconost, дедлайн, качество кода, ПО, Программирование, разработка, Софт, Управление продуктом, управление разработкой
Надеюсь, что смог привлечь ваше внимание таким провокационным (и, признаться, утрированным) заголовком. Хорошо. Теперь позвольте его переформулировать в чуть более изящном и менее завлекающем виде:
В принципе, софт можно написать либо вовремя, либо хорошо, но не то и другое одновременно*
* за исключением считанных случаев в сложившихся высокопроизводительных командах
Вот уже несколько месяцев я размышлял о том, почему создание качественного софта плохо сочетается с оценочными сроками и планированием вообще. За свою карьеру я видел проекты, выстроенные по самым разным моделям (каскадная, подлинно гибкая, гибко-каскадная), и у всех них была одна общая черта: независимо от того, над каким проектом мы работаем, если он делался «по науке» (т.e., мы не позволяли себе грязных уловок, из-за которых нам бы потом снились кошмары), то мы всегда срывали сроки.
С другой стороны, всякий раз, когда проект сдавался «вовремя», это означало, что по ходу дела неизбежно пришлось сократить его объем, либо срезать столько углов, что во время реализации накапливались горы технического долга, практически гарантировавшие, что проект придется переписывать вскоре после запуска. Поэтому я стал задумываться: на самом ли деле можно считать, что проект сдан «в срок», если в результате мы имеем уродливый, неудобный в поддержке, нашпигованный багами и, прямо скажем, более неприглядный вариант кода по сравнению с тем, что мы исходно пытались сделать?
Переведено в Alconost
Читать полностью »
Теория счастья. Проклятие режиссёра и проклятые принтеры
2018-09-07 в 9:27, admin, рубрики: recreational science, дедлайн, занимательная математика, Занимательные задачки, кривая Лоренца, математика, Научно-популярное, пуассоновский процесс, распределение пуассона, теория вероятности и мат статистика, теория счастья, числа СтирлингаПродолжаю знакомить читателей Хабра с главами из своей книжки «Теория счастья» с подзаголовком «Математические основы законов подлости». Это ещё не изданная научно-популярная книжка, очень неформально рассказывающая о том, как математика позволяет с новой степенью осознанности взглянуть на мир и жизнь людей. Она для тех кому интересна наука и для тех, кому интересна жизнь. А поскольку жизнь наша сложна и, по большому счёту, непредсказуема, упор в книжке делается, в основном, на теорию вероятностей и математическую статистику. Здесь не доказываются теоремы и не даются основы науки, это ни в коем случае не учебник, а то, что называется recreational science. Но именно такой почти игровой подход позволяет развить интуицию, скрасить яркими примерами лекции для студентов и, наконец, объяснить нематематикам и нашим детям, что же такого интересного мы нашли в своей сухой науке.
Опубликованные главы:
• Введение в мерфологию
• Закон арбузной корки и нормальность ненормальности
• Закон зебры и чужой очереди
Мы порассуждаем о цейтнотах, дедлайнах и о невовремя ломающихся принтерах.
Правило 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 и получил следующие результатыЧитать полностью »
Разработчики рассказывают о вырезанных из игр фичах
2018-06-11 в 9:49, admin, рубрики: дедлайн, Дизайн игр, разработка игр, Управление продуктом, управление проектами, управление ресурсами
Процесс создания игр часто связан с отсечением лишнего.
На множество отточенных готовых продуктов, выбравшихся на рынок, приходятся тысячи идей, не доживших до этого, или со временем мутировавших настолько, что в них невозможно узнать их первоначальный вид.
Gamasutra попросила разработчиков игр рассказать о самых запомнившихся идеях, которые пришлось вырезать, и о причинах отказа от них.
Митч Гителмэн, Harebrained Schemes
Разумеется, огромное количество фич сваливается в пропасть между амбициями и практической осуществимостью. По словам Митча Гителмэна, этот разрыв стал ещё больше, когда разработчики начали продавать свои проекты на платформах краудфандинга; он никогда не видел, чтобы масштабы ожиданий когда-нибудь увеличивались.
«Во время нашей кампании на Kickstarter по сбору средств на Shadowrun Returns в 2012 году Harebrained Schemes пришлось получить жёсткий урок управления масштабом проекта».
Читать полностью »
Дизайн в условиях хакатона
2018-03-29 в 7:43, admin, рубрики: touch instinct, Блог компании Touch Instinct, веб-дизайн, дедлайн, дизайн, дизайн интерфейсов, дизайн мобильных приложений, дизайнеру, интерфейсы, хакатон, Хакатоны
Меня зовут Алиса, я старший дизайнер в Touch Instinct. Мы — аутсорс-компания. Скорость — один из важнейших критериев оценки нашей работы, наравне с качеством. Иногда для подготовки предложения для нового клиента нужно изучить, придумать и воплотить в жизнь концепцию приложения всего за пару дней. В таких ситуациях нет права на ошибку.
В марте я выступала на хакатоне, который мы организовали вместе с Партией еды. Рассказала участникам, как сделать хорошо за короткий срок. По мотивам лекции подготовила статью-памятку. Она будет полезна участникам команд, которые планируют участвовать в хакатонах, а также начинающим дизайнерам. Читать полностью »
Мы перерабатываем. Ну и что такого?
2017-03-21 в 8:51, admin, рубрики: crunch, выгорание, дедлайн, Карьера в IT-индустрии, управление временем, управление разработкой
[Прим. пер.: в оригинале используется слово crunch, означающее что-то вроде «напряжённо работать, чтобы успеть в срок». Статья написана про игровую индустрию, но, как мне кажется, применима к разработке любых продуктов.]
Переработки — прискорбная особенность нашей индустрии. Что с ней делать, пока кто-нибудь не решит её окончательно?
Обсуждая переработки, мы обычно спорим о том, бывают ли условия, при которых они приемлемы — «хорошие», а не «плохие» переработки — и что нужно изменить в индустрии в целом чтобы избавиться от «плохих». Я согласен, что было бы отлично, если бы индустрия начала меняться сверху: руководители могли бы взять на себя больше ответственности за улучшение условий работы и обеспечение более дружелюбной и устойчивой среды для разработчиков игр. Но такие изменения скорее всего будут медленными и постепенными. В мире огромное количество студий, и взгляды их руководителей на решение этой проблему резко противоположны. Их слишком много для единогласного принятия.
Это значит, что хотя и есть причины ждать улучшений, всё равно существует большая вероятность столкнутся в своей карьере с «плохими» переработками, и чем дольше ваша карьера, тем вероятность выше. «Если не нравится — уходите» — популярная среди плохих начальников и интернет-комментаторов песня, но по разным причинам иногда это невозможно. Например, это может поставить под угрозу вашу работу, а найти новую быстро не получится.
Поэтому, если вы только что начали работать в этой индустрии и встретились со своим первым «горящим сроком», или только решаете, стоит ли заниматься играми, услышав все эти ужасные истории о переработках, вот мои размышления о том, как возникают «напряги», и как пережить их.
Читать полностью »
Прокрастинация. Как посадить в клетку демона, который мешал двигаться к цели
2017-02-06 в 5:35, admin, рубрики: Блог компании SmartProgress, дедлайн, прокрастинация, Учебный процесс в IT, цели и задачи, Читальный залАвтор иллюстрации — John Kenn
Почему больше времени уходит на изучение редких аутоиммунных заболеваний, чем на поиск хорошего врача, а грязная посуда кажется важнее, чем составление бизнес плана?
Прокрастинация — преступление, в котором виновен каждый.
Главный ингредиент успеха — действие. Поддаваться прокрастинации — то же самое, что вообще ничего не делать.
Еще одна проблема в том, что мы все-таки выполняем задуманное. Да, мы откладываем до последнего и ждем дедлайна, но все же беремся за дело. И это плохо, ведь появляется ложная уверенность в завершении задачи независимо от времени начала действий.
Еще хуже когда сроков нет вообще. Как долго мы сможем откладывать, пока возможность не будет упущена окончательно?
У жизненных целей нет дедлайна, а значит и нет последствий его срыва. Так что откладывать мы можем бесконечно и не принимать никаких действий. Но без действий не будет и результатов.
Читать полностью »