Рубрика «управление разработкой» - 116

Недавно после очередного Team Building’a получил от одного Коллеги-Графомана письмо-притчу про большую кнопку «сделать всё хорошо». Он и раньше баловался изобретением велосипедов, но, в этот раз конструкция показалась мне очень удачной. Кому интересно — прошу-приглашаю под кат. С его разрешения дословно:

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

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

Если пройтись по зарубежным сайтам с запросом «product requirements document», то можно найти креативные и убедительные статьи про то, что техническое задание (ТЗ, PRD) умерло. Отчасти с этим нужно согласиться — при разработке продукта с нуля прототипирование выглядит гораздо интереснее и эффективнее, чем тома записей заказчика, порой ну очень непрофессиональные. Однако, если речь идёт о доработке базовой системы, то дело принимает совершенно другой оборот. Мы сталкиваемся и с доработкой, и с заказной разработкой, поэтому на ТЗ собаку съели, если повар нам не врёт. В общем, сегодня — о тех самых классических технических заданиях, которые пишутся на доработку купленного и установленного программного обеспечения. Короче, о наболевшем.

Техническое задание на доработку: 10 правил и немного занудства - 1

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

Кого волнуют баги продукта, если он успешно продается - 1
Изображение сайта media.licdn.com

Как утверждает венчурный инвестор и программист Лео Половетс, в сегодняшнем мире Saas, API и облачной инфраструктуры проработанная техническая составляющая редко становится причиной успеха или провала программного продукта. Современные технологии теперь позволяют разработать его очень быстро с минимальными затратами. Казалось бы, это как раз то, что нужно стартаперам.

По данным CB Insights, только 5% стартапов прогорают по причине слабой технической реализации. Большинство провалов случается в результате неверного позиционирования продукта, отсутствия грамотной маркетинговой стратегии, плохих специалистов по продажам, неверной бизнес-модели. Наличие или отсутствие высококвалифицированных инженеров практически не играет никакой роли, делают вывод исследователи.

Если обратиться к примеру самых успешных технологических стартапов мира (Uber, Airbnb, Snapchat, Pinterest и прочие), мы не увидим сложных программных решений. Зато очевидным преимуществом этих компаний является удачная бизнес-модель. В купе с активным продвижением, эти сервисы смогли стать одними из самых востребованных и дорогих стартапов мира. Но вряд ли они нанимали десятки инженеров, чтобы разработать сервис и подготовить его к запуску, сомневается Половетс.Читать полностью »

При разработке каких-либо продуктов у команды зачастую возникает желание перестать бороться с текущим состоянием проекта и переписать всё снова, на этот раз "правильно" и "по науке". Обычно такие порывы не одобряются, но в этот раз я бы хотел предложить к прочтению перевод поста Hugo Baraúna, посвященного тому, какие вопросы нужно задать себе, если всё же решили переписывать.

Также, как и большой рефакторинг, переписывание продукта — непростая штука. За много лет мы приобрели достаточно опыта, чтобы указать, что вам следует обдумать, планируя и осуществляя процесс переписывания.

Будут ли обе платформы существовать одновременно, или нет?

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

«Бег с препятствиями»: Повышаем эффективность разработки сервисов - 1

Фото Paul CC

Занимаясь разработкой IaaS-провайдера, мы в 1cloud не понаслышке знаем о том, как важно грамотно организовать рабочий процесс всей команды. Недавно мы публиковали материал, в котором обсудили 13 вещей, которые не стоит говорить разработчикам и тестировщикам, а в другом посте затронули тему корпоративной культуры организаций.

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

О роли DevOps в ИТ — мнения экспертов - 1
Изображение сайта tricentis.com

Существующие реалии буквально требуют от разработки программного обеспечения еще больше сокращать время выполнения проекта: от возникновения идеи до выпуска готового продукта. С завидной периодичностью заказчики просят реализовать проект «вчера», чтобы его не скопировал «сегодня» кто-то другой. И, конечно же, бюджет на то, чтобы сделать невозможное, как всегда, ограничен.

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

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

Когда разработчику вредно совмещать программирование и техническую поддержку ПО - 1
Изображение сайта easywebstudio.ru

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

Так или иначе, перспектива совмещения техподдержки и разработки программного обеспечения радует далеко не всех программистов. Работа специалиста технической поддержки зачастую оказывается серьезным испытанием для нервов разработчика. Более того, такое совмещение часто сказывается на его результативности. Головному мозгу требуется время для переключения с одной деятельности на другую. Для многих программистов это означает несколько потерянных часов, которые тратятся на то, чтобы вернуться из мира людей в мир алгоритмов и кодирования. А неудачное общение с разгневанным пользователем и вовсе может выбить некоторых разработчиков из колеи на весь день.Читать полностью »

Человеческий фактор остается самым сильным, но выгодным риском в разработке ПО - 1
Изображение с сайта projectimo.ru

Даже в такой продуманной и формализованной сфере, как разработка программного обеспечения, не перестает быть актуальным вопрос управления рисками. Можно ли вообще управлять неопределенностью, случайными величинами?

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

А риск того, что проект неожиданно покинут ключевые разработчики, вообще приводит в ужас многих риск-менеджеров. Читать полностью »

Как Линус Торвальдс сделал разработку ПО свободнее - 1

«Я делаю свободное ПО, потому что считаю это единственным правильным способом разработки»

Некоторые считают Линуса Торвальдса, создателя операционной системы Linux и репозитория Git, просто везучим человеком. Кому-то он, наоборот, кажется целеустремленным энтузиастом своего дела. Однако никто не будет спорить с тем, что благодаря исключительной одаренности Торвальдса появилась операционная система, которая распространилась по всему миру.

Более того, принципиально важным для ее создателя было бесплатное использование и свободное редактирование исходного кода ОС. Вокруг Linux образовалось огромное opensource-сообщество, благодаря которому система развивается и по сей день: постоянно появляются новые сборки и новые операционные системы на базе ядра Linux.Читать полностью »

18 июля 2016 года вступили в силу новый Административный регламент предоставления государственной услуги по государственной регистрации программы для ЭВМ, а также новые Правила регистрации программ и баз данных. Таким образом, прекращает действие Административный регламент 2008 года. Понятно, что если вы по каким-то причинам регистрируете программы в Роспатенте (зачем их регистрировать — мы обсуждали здесь ранее), то с 18 июля нужно пользоваться новой формой заявления.

С 18 июля новый порядок регистрации программ для ЭВМ в Роспатенте. Что изменилось? - 1

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


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