Управление разработкой *

Аналитики Gartner в апреле сообщили, что мировые траты на дата-центры по сравнению с прошлым годом возрастут и перевалят за $170 млрд. Во столько Forbes оценивает бренд Apple, и именно такая сумма проходит через все магазины крупнейшего ретейлера в США Walmart. В этой статье мы рассмотрим, куда идут такие деньги в контексте ЦОД, и поговорим о том, из чего складываются затраты на виртуальную и физическую инфраструктуры.

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

Статья привлекла меня 3-мя интересными на мой взгляд аспектами: 1) сама тема очень злободневна и статья получила множество комментариев, 2) публикация набрала рейтинг более 100, 3) при этом она не несет в общем-то никаких реальных объяснений, а построена на очень спорных аргументах — лозунгах.

В связи с тем, что относительно большая (и очень громкая) часть IT живёт в очередном пузыре доткомов (теперь уже стартапов), у некоторых представителей этого племени, а в особенности у всяких евангелистов и даже HR появилась иллюзия следующего свойства.

Мол, какой-то девайс, фреймворк или способ работы резко поднимает успешность предприятия. Например, «мы все используем MacBook, и у нас уже третий раунд инвестиций». Или «мы решили открыть travel-агентство, и нанимаем только тех программистов, которые не вылезают из путешествий; мы хотим, чтобы все сотрудники разделяли наши ценности, и у нас уже оборот 100 млн долларов». Или «как только мы внедрили React + Vue + Angular, наши дела пошли в гору, и нас купил Google». И так далее.

На первый взгляд кажется абсурдом? — Да, но признаем: хайп и гвалт есть несомненные сопутствующие элементы современного IT-мира. Любое явление, находящееся на острие общественного внимания, а IT, безусловно, из таких, не может не впитать в себя характерные черты социума своего времени. В частности, тенденцию к превалированию формы над содержанием.

Несколько лет назад примерно с такой фразой ко мне пришел один из ведущих программистов. Давайте назовем его Иваном (все персонажи вымышленные, а любые совпадения случайны). Он собирался переехать жить за город и каждый день ездить в офис ему стало неудобно. У Ивана был приличный послужной список, несколько лет работы в компании и большой вагон доверия. Тогда мы договорились, что Иван будет работать удаленно понедельник и пятницу, а вторник-четверг он приезжает в офис с утренним графиком.

Добрый день, уважаемые хабравчане. Ранее я рассказывал, что основная деятельность Банка в части ИТ процессов, была организована на ITIL. Исключением стал только процесс управления изменениями. Вторая (и заключительная) часть посвящена внедрению элементов гибких методологий в Банке в процессах управления изменениями в ИТ.

Описание проблемы

Я столкнулся со следующими проблемами при анализе существовавшего процесса:

• 80% задач поступает ad hoc
• приоритеты задач постоянно меняются
• нет возможности осуществлять планирование работ
• отсутствует гармоничность в развитии систем
• нет «установленных правил игры» при реализации изменений

Это история о нас. Тем из нас, у кого 10 и более лет опыта работы в сфере ПО, описанное в статье может показаться знакомым. А те, кто еще на ранних этапах карьеры, смогут узнать, что ждет их в близком и не очень будущем, и получить пару советов.

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

Первые шаги

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

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

Избегайте этой ловушки, не следует придавать антропоморфные черты Ларри Эллисону.
Брайэн Кантрилл

Похоже, что в Oracle приняли решение окончательно избавиться от трудовых ресурсов, составляющих костяк Sun Microsystems. Массовые увольнения затронули около 2500 сотрудников, работающих над операционной системой Solaris, платформой SPARC и системами хранения данных ZFS Storage Appliance.

Это не рядовая трансформация — оптимизация, а настоящая бойня. По мнению создателя системы динамической отладки Dtrace Брайэна Кантрилла (Bryan Cantrill) на сей раз нанесен непоправимый ущерб, в результате потери 90% производственных кадров подразделения Solaris, включая все руководство.

1. Менеджмент некой компании уделяет большое внимание мотивации сотрудников.
2. Для поощрения высоких результатов было решено выдавать премии командам по результатам соблюдения сроков и бюджетов проектов.
3. Решение было доведено до сотрудников.
4. Одна из команд занималась доработками зрелого и стабильного проекта, успешно выполнила все условия, получила премию.
5. Другой команде достался новый сложный проект, люди работали над ним с неподдельным энтузиазмом.
6. К сожалению, и запланированные сроки, и бюджет оказались превышены в разы.
7. Получившийся в результате продукт дал компании рекордную прибыль.

Если вы менеджер в этой компании, то станете ли премировать вторую команду и почему?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

20 сентября в офисе Wrike в Санкт-Петербурге мы встретимся составом продуктовых аналитиков и продакт-менеджеров, чтобы постараться ответить на эти вопросы.

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

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

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

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

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

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

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

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

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


А по техническому заданию был гоночный болид для Формулы 1

«Чтение научной статьи – то, что заставит вас чувствовать себя глупее некуда», – пишет ученый Адам Рубин (Adam Ruben) в своей юмористической колонке для журнала Science. Адам прав: читая статью из рецензируемого научного журнала, многие из нас начинают с оптимизма («В конце концов это всего лишь несколько страниц»), а заканчивают отчаянным желанием срочно сменить сферу деятельности на такую, где научных статей или вовсе нет, или их пишут как-то иначе. На самом деле проблема не в статьях – а в том, как мы их выбираем и читаем.

О том, что советуют делать по этому поводу сами ученые, расскажем ниже.

Когда речь заходит о разработке, менеджеры и управленцы сразу вспоминают накопившийся массив задач, которые ждут своей очереди, непредсказуемые сроки их реализации, имеющие свойство постоянно меняться, натянутые отношения с IT-отделом, который использует систему «свой-чужой», и множество других проблем, тормозящих развитие бизнеса. Чтобы решить все эти проблемы, необходимо научиться грамотно ставить задачи и общаться с разработчиками. О том, как менеджеры должны ставить задачи, чтобы они были выполнены в срок и в соответствии с заданием, рассказывает Николай Хлебинский, СЕО и сооснователь платформы Retail Rocket.