Вступление

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

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

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

Далее привожу все найденные мной факторы, которые привели меня к столь неприятному положению дел.

На конференции Monitorama Пит Чеслок из Threat Stack провел параллель между историей строительства шведского корабля «Васа» и провальными проектами по разработке. Делимся с вами отрывком его выступления.



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

Наш отдел разработки и управления проектами как-то раз решил поехать куда-нибудь на ТМ-билдинг. Каждый ткнул пальцем в карту и так получилось, что все попали в Амстердам. В целом всё прошло прекрасно, мы отлично провели время, а заодно заглянули в гости в офис Booking.com — компании, услугами которой пользуются многие сотрудники ТМ. Там же работают многие хабрапользователи, в числе которых и CurlyBrace, благодаря которому мы смогли посетить офис.



3 пасхалки под катом.

Лета как будто и не было: кажется, буквально вчера все взахлеб обсуждали июньскую презентацию с WWDC, на которой представители Apple рассказали общественности об iOS 11, и вот уже считанные недели отделяют нас от публичного релиза. А значит, пришло время освежить в памяти все, что было сказано о новом девайсе, и морально подготовиться к неизбежным переменам, которые ждут всех, кто имеет дело с мобильными приложениями. И это касается не только разработчиков. В новой версии было значительно переработан App Store, а значит достанется и маркетологам, и контент-менеджерам, и дизайнерам — измененная среда продвижения задает новые правила и приоритеты, тем самым заставляя меняться и продукт.

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

Комплексная автоматизация – это оптимизация всех областей деятельности компании.

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

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

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

Это последняя статья из моего цикла. В ней будет много о менеджерской и организационной сторонах разработки.

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

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

О(n²): Совещание равноправных участников. n человек обсуждают вопрос, причем для достижения взаимопонимания, каждому участнику нужно пообщаться с каждым. Всего будет осуществлено n*(n-1)/2 социальных взаимодействий (эквивалентно задаче подсчета числа рукопожатий в группе из n человек), т.е сложность алгоритма О(n²). Казалось бы, за счет того, что общение одновременно могут осуществлять n/2 пар людей, оценка по времени – О(n), однако на реальных совещаниях в один момент времени говорит только один человек, поэтому оценка для худшего случая — О(n²). Если время взаимодействия – 5 минут и для достижения полного взаимопонимания в группе требуется две итерации, то совещание трех человек продлиться 30 минут, четырех – час, пятерым потребуется 1 час 40 минут для нахождения общего решения (что подозрительно похоже на правду). Если же число итераций зависит от числа участников, мы получаем еще более печальные оценки.

Но не все так плохо!

При старте проекта многие задаются вопросом «Где вести тестовую документацию?».
В этой статье мне хотелось бы рассказать вам об инструменте Test Management for JIRA (в данном случае плагин рассматривается как инструмент) для того, чтобы удобно, эффективно и качественно составлять и управлять тест дизайном проекта.

Почему нам стоит обратить внимание к этому инструменту? Потому что он:

— Удобно устанавливается, поддерживается
Установка происходит через раздел управление плагинами в JIRA

— Есть связь с JIRA
Да, поначалу этим не удивишь, но фишка в том, что он идет как плагин к JIRA и не нужно отдельно интегрироваться с другими инструментами тест менеджмента.

Как это улучшит мою работу?

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

Это не только улучшит вашу работу, но и ускорит ее.

Когда мы первый раз пришли в офис Avito на встречу, то просто смотрели по сторонам, выпадали из реальности и фотографировали отдельные штуки на телефоны, чтобы потом показать коллегам и знакомым. Второй визит получился более осмыслённым — пришло понимание, что это тот случай, когда офис — не набор мест для валяния и удачно расставленных спотов-кормушек, а сочетание абсолютно функциональных элементов. То есть не навороты и красота (хотя и она есть), а настоящая энциклопедия юзабилити офисного пространства. «А давайте сделаем фоторепортаж из вашего офиса, это и полезно, и интересно», — предложили мы после второй встречи. Ну а где вторая, там и третья — и два человека (в составе Boomburum +1) из нашей команды ТМ отправились в Avito, чтобы послушать, поспрашивать, поснимать. Вышло интереснее, чем мы могли этого ожидать. И да, в репортаже нет ни одного постановочного кадра.

Для разработки своего решения для поддержки клиентов мы выбрали сервис Gmail, так как это один из самых популярных почтовых клиентов. А для расширения его возможностей — готовую библиотеку InboxSDK. На момент разработки она обладала нужным нам функционалом, и такое решение помогло нам быстро выйти на рынок с первой версией продукта и набрать пользовательскую базу. С другой стороны, InboxSDK — закрытая библиотека от стороннего разработчика и она обладала недостатками, которые в дальнейшем надо было решать.

Опыт использования GrayLog в наших проектах и как это повлияло на качество продуктов.

В продуктовой разработке постоянно и довольно остро стоит вопрос эффективности. Как построить процесс так, чтобы он был оптимален с точки зрения бизнеса, роста сотрудников, изменяемости, прозрачности и многих других факторов? Где та самая «серебряная пуля», которая позволит решить сразу все проблемы и избавит вас как руководителя от головной боли?

На звание этой «серебряной пули» по очереди претендуют модные (и не очень) методологии разработки: Scrum, Kanban, XP, RAD, FDD и т. п. Регулярно появляются новые способы и подходы, фреймворки и инструменты. Бизнес-консультанты приходят в компании и делятся своими ноу-хау за немалые деньги, рассказывая, как правильно. А при этом хорошо бы ещё и дёшево, не так ли?

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

Давайте подумаем, что требуется от процесса, какие проблемы нужно решить и какие подходы для этого используют. А заодно я расскажу о том, как делаем мы в Badoo. Это уже третий мой пост подряд в нашем блоге на Хабре. Но на всякий случай представлюсь снова: я – Илья Агеев, руковожу QA в Badoo.

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

Китай с 2013 года — мировой лидер по количеству владельцев смартфонов, а сегодня это уже крупнейший в мире рынок приложений. Здесь речь идет о доходах в размерах более 25 млрд. долларов по состоянию на 2016 год и 42 млрд. долларов — к 2020 году (согласно прогнозам).

Да, китайский рынок действительно впечатляет. И не в последнюю очередь — за счет большого числа владельцев смартфонов: 1,3 миллиарда потенциальных покупателей вашего приложения (и это число растет). Пользователи из Китая сегодня тратят в пять раз больше, чем два года назад, а когда речь идет о технологиях и гаджетах, они оказываются просто ненасытны.

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

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

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

Сегодня мы запускаем на канале Технострим серию интервью с техническими руководителями IT-компаний, ведущий программы — технический директор медиапроектов Павел Щербинин. Первым у нас в гостях побывал Иван Ремень — руководитель группы разработки в Почте Mail.Ru.

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

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

Давайте подумаем и обозначим проблемы, которые могут возникнуть в процессе разделения задач, и способы их решения. В этом посте будут рассмотрены основные принципы декомпозиции задач при работе в команде. Меня зовут Илья Агеев, я – глава QA в Badoo. Сегодня расскажу, как workflow влияет на декомпозицию, насколько отличаются тестирование и выкладка задач, которые появляются в результате декомпозиции, и каких правил стоит придерживаться, чтобы процесс разработки проходил гладко для всех участников.

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

Всё началось, когда автор Ruby on Rails признался миру:

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

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

Что самое ценное для IT-компании? Что является главным активом и ресурсом почти для каждой IT-компании? На что компания тратит больше всего денег? Какая статья затрат является самой большой? На обслуживание какого ресурса у вас уходит больше всего денег? Не сильно ошибусь, если скажу, что ответом на все эти вопросы является “Команда компании”. Именно ваша команда делает проекты, двигает вашу компанию вперед и зарабатывает деньги, и именно на зарплаты, бонусы, налоги, оборудование рабочих мест и прочие прямые и косвенные выплаты вашей команде приходится основная масса затрат компании.

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