Рубрика «дедлайн»

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

Стресс и выгорание в мире разработки ПО - 1

Автор: Sow Ay

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

Если вспомнить конкретно 2017 год, то он стал для меня весьма неприятным. Я регулярно испытывал панические атаки, сидел на релаксантах и пытался писать код, находясь под серьёзным давлением дедлайнов и новых ответственностей. Тогда я как раз унаследовал от своего предшественника должность главы отдела информационных технологий. Теперь я отвечал за небольшую команду разработчиков. При этом наш стартап дал многим партнёрам множество обещаний. Моей же задачей была их реализация, и я мог их либо нарушить, либо выполнить. У меня получилось и то и другое.Читать полностью »

в 8:04, , рубрики: Анализ и проектирование систем, Блог компании ДомКлик, дедлайн, проектирование, разработка, управление персоналом, управление проектами, управление разработкой

2022 год научил нас быстро менять приоритеты для оперативного реагирования на внешние факторы. В наших целях была зафиксирована ключевая задача по отказу от софта вендора в пользу собственных решений, разработанных на основе микросервисной архитектуры. Стоял вполне комфортный срок: полностью завершить переход до конца года, и команды планомерно шли к этой цели, наряду с разработкой менее масштабных, но тоже важных фич. Но в связи со вполне реальными рисками преждевременного ухода вендора из РФ сроки доработок сократились с полугода до одного месяца (почти как в известной шуткеЧитать полностью »

в 5:39, , рубрики: gtd, апатия, дедлайн, депрессия, здоровье, Лайфхаки для гиков, мозг, продуктивность работы, прокрастинация

Как программировать если совсем не хочется? План спасения на случай перегорания или дедлайна - 1

Никакой воды в этой статье, только описание конкретного плана действий в случае если вы перегорели, у вас дедлайн, прокрастинация, депрессия, а также методики и советы помогающие привести этот план в действие.

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

в 11:23, , рубрики: Wirex, Блог компании Wirex, дедлайн, оценка времени, оценка стоимости проекта, оценка трудозатрат, Программирование, сроки, Статистика в IT, управление разработкой

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

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

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

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

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

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

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

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

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

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

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

в 10:03, , рубрики: Alconost, software, алконост, Блог компании Alconost, дедлайн, качество кода, ПО, Программирование, разработка, Софт, Управление продуктом, управление разработкой

Приходится выбирать, какой софт вам нужен: написанный вовремя или качественный - 1

Надеюсь, что смог привлечь ваше внимание таким провокационным (и, признаться, утрированным) заголовком. Хорошо. Теперь позвольте его переформулировать в чуть более изящном и менее завлекающем виде:

В принципе, софт можно написать либо вовремя, либо хорошо, но не то и другое одновременно*

* за исключением считанных случаев в сложившихся высокопроизводительных командах

Вот уже несколько месяцев я размышлял о том, почему создание качественного софта плохо сочетается с оценочными сроками и планированием вообще. За свою карьеру я видел проекты, выстроенные по самым разным моделям (каскадная, подлинно гибкая, гибко-каскадная), и у всех них была одна общая черта: независимо от того, над каким проектом мы работаем, если он делался «по науке» (т.e., мы не позволяли себе грязных уловок, из-за которых нам бы потом снились кошмары), то мы всегда срывали сроки.

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

Переведено в Alconost
Читать полностью »

в 9:27, , рубрики: recreational science, дедлайн, занимательная математика, Занимательные задачки, кривая Лоренца, математика, Научно-популярное, пуассоновский процесс, распределение пуассона, теория вероятности и мат статистика, теория счастья, числа Стирлинга

Продолжаю знакомить читателей Хабра с главами из своей книжки «Теория счастья» с подзаголовком «Математические основы законов подлости». Это ещё не изданная научно-популярная книжка, очень неформально рассказывающая о том, как математика позволяет с новой степенью осознанности взглянуть на мир и жизнь людей. Она для тех кому интересна наука и для тех, кому интересна жизнь. А поскольку жизнь наша сложна и, по большому счёту, непредсказуема, упор в книжке делается, в основном, на теорию вероятностей и математическую статистику. Здесь не доказываются теоремы и не даются основы науки, это ни в коем случае не учебник, а то, что называется recreational science. Но именно такой почти игровой подход позволяет развить интуицию, скрасить яркими примерами лекции для студентов и, наконец, объяснить нематематикам и нашим детям, что же такого интересного мы нашли в своей сухой науке.

Опубликованные главы:

 •  Введение в мерфологию
 •  Закон арбузной корки и нормальность ненормальности
 •  Закон зебры и чужой очереди

Теория счастья. Проклятие режиссёра и проклятые принтеры - 1

Мы порассуждаем о цейтнотах, дедлайнах и о невовремя ломающихся принтерах.

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

в 10:45, , рубрики: atlas, express.js, Git, jquery, mysql, terraform, terratest, Wirex, Блог компании Wirex, дедлайн, Программирование, Системы управления версиями, сроки, Статистика в IT

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

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

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

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

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

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

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

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

в 9:49, , рубрики: дедлайн, Дизайн игр, разработка игр, Управление продуктом, управление проектами, управление ресурсами
image

Процесс создания игр часто связан с отсечением лишнего.

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

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

Митч Гителмэн, Harebrained Schemes

Разумеется, огромное количество фич сваливается в пропасть между амбициями и практической осуществимостью. По словам Митча Гителмэна, этот разрыв стал ещё больше, когда разработчики начали продавать свои проекты на платформах краудфандинга; он никогда не видел, чтобы масштабы ожиданий когда-нибудь увеличивались.

«Во время нашей кампании на Kickstarter по сбору средств на Shadowrun Returns в 2012 году Harebrained Schemes пришлось получить жёсткий урок управления масштабом проекта».
Читать полностью »

в 7:43, , рубрики: touch instinct, Блог компании Touch Instinct, веб-дизайн, дедлайн, дизайн, дизайн интерфейсов, дизайн мобильных приложений, дизайнеру, интерфейсы, хакатон, Хакатоны

Дизайн в условиях хакатона - 1

Меня зовут Алиса, я старший дизайнер в Touch Instinct. Мы — аутсорс-компания. Скорость — один из важнейших критериев оценки нашей работы, наравне с качеством. Иногда для подготовки предложения для нового клиента нужно изучить, придумать и воплотить в жизнь концепцию приложения всего за пару дней. В таких ситуациях нет права на ошибку.

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

в 8:51, , рубрики: crunch, выгорание, дедлайн, Карьера в IT-индустрии, управление временем, управление разработкой

image

[Прим. пер.: в оригинале используется слово crunch, означающее что-то вроде «напряжённо работать, чтобы успеть в срок». Статья написана про игровую индустрию, но, как мне кажется, применима к разработке любых продуктов.]

Переработки — прискорбная особенность нашей индустрии. Что с ней делать, пока кто-нибудь не решит её окончательно?

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

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

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

12
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js