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

«Почему ж всё так плохо?» — каждый раз я задаюсь этим вопросом, когда приходится иметь дело с очередным кодом, продуктом или API, созданными для внутренних нужд в непрофильной организации.

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

И деньги ничего не решают: ужасный код и ужасные продукты пишут как маленькие бедные ВУЗы, у которых денег хватает только на рабский труд аспирантов, так и крупные и богатые компании, включая IT-компании, включая зарубежные: несколько раз сталкивался с кодом, который писали зарубежные подрядчики и каждый раз от него хотелось рыдать и биться головой об стену.

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

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

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

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

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

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

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

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

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

Что удалось получить в результате:

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

Давайте расскажу, как мы этого добились.

Ланнистеры всегда платят свои долги! (и технические тоже) - 1

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

image Ивар Якобсон, почти легенда — основоположник UML, RUP, SEMAT — неугомонен, продолжает попытки навести порядок в индустрии разработки ПО. И на вопрос: «Что помогает оставаться таким активным» отвечает: «Having fun!» :)Читать полностью »

Деловая игра Kanban-пицца в офисе Туту.ру - 1

Приглашаем всех желающих 14 сентября поучаствовать в деловой игре под названием Kanban-пицца! Мы в игровой форме расскажем о принципах и правилах Kanban, обсудим аспекты применения методологии и ее преимущества для ИТ-отрасли, а также поделимся опытом реального построения процессов.
Читать полностью »

Бизнес в России учится делать не только скучные проекты по автоматизации бизнес-процессов, но и создавать IT-решения, способные помочь в борьбе с конкурентами. Например, проекты по предсказанию спроса, real-time offer management, оптимизации логистики, микротаргетированию. Такие сложные задачи отличаются от типовых внедрений CRM или выбора CMS. Надо иначе искать разработчиков, иначе мотивировать, думать об IT-архитектуре и методологии управления.

Шпаргалка — навигация по темам, которые стоит знать руководителю компании и топ-менеджеру, чтобы грамотно реализовать IT-проекты нового уровня сложности. По каждой теме будет много ссылок на статьи, интервью, обзоры и видео.

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

Встреча в Петербурге «Роль аналитика в принятии важных продуктовых решений» - 1

Что может помочь менеджеру по продукту минимизировать риски при принятии решений по развитию тех или иных фич? Насколько веским может и должно быть слово аналитика в процессе разработки? Есть ли у продуктовых аналитиков какой-то иной инструментарий, кроме количественных данных?
20 сентября в офисе Wrike в Санкт-Петербурге мы встретимся составом продуктовых аналитиков и продакт-менеджеров, чтобы постараться ответить на эти вопросы.

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

С частью 1 можно ознакомиться, перейдя по ссылке

IV ОПРЕДЕЛЯЕМ ЦЕЛИ, ПРОЕКТА

Цель не обязательно должна достигаться. Порой это просто направление двигаться дальше.
Брюс Ли.

Практика формирования требований в ИТ проектах от А до Я. Часть 2. Цели и Потребности - 1

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

Цель данной группы работ: определить основные задачи, которые ставят перед собой группы заинтересованных лиц, участвующих в проекте.
Читать полностью »

Руководство по локализации приложений для китайского рынка, часть 2 - 1
Перед вами — вторая часть руководства по локализации приложений для китайского рынка. Если первую часть вы не читали — она здесь. Итак, сразу к делу.

Переведено в Alconost

6. Внедрение местных способов оплаты

Привычные на Западе способы оплаты (кредитные карты, например), в Китае используются редко, поэтому нужно применять местные инструменты. Мобильные операторы (China Telecom, China Unicom и China Mobile) позволяют делать платежи из приложений. Прямая оплата через оператора составляет около 75% от всех платежей.

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

В комментариях к нашему предыдущему посту пользователь raguanec задал вопрос, окажется ли провальным внедрение CRM-системы, если обратиться к небольшим компаниям или частным разработчикам. Это был лучший из заданных в тот день вопросов, и тогда же мы решили ответить большой статьёй, в которой рассмотрим, каково оно, заказывать корпоративный софт у разных типов подрядчиков, оценим плюсы-минусы и побочные эффекты. Но за две недели фантазия разыгралась и мы решили не просто побухтеть, но и провести очередной эксперимент в нашем стиле. Получилось захватывающе и местами озорно. Enjoy!

Подрядчик для CRM: ищем пути провалить проект - 1
А по техническому заданию был гоночный болид для Формулы 1
Читать полностью »


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