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

За последние два года существования команды в общении с клиентами удалось выделить ряд ключевых вопросов, ответы на которые определяют судьбу проекта. Эти вопросы постепенно сформировались в чек-листы, подобные тем, что используют пилоты для проверки всех систем самолета перед запуском двигателя.



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

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

Юрий Гурский — человек, о котором сегодня много пишут. Представитель немногочисленных белорусских предпринимателей, ныне вице-президент Mail.ru Group и человек, частично ответственный за успех MSQRD.

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

Юрий нашёл время для того, чтобы пообщаться с нами и ответить если не на все, то хотя бы на часть вопросов.

У Самата samat Галимова интересный опыт: от практики в «Яндексе», через Bookmate, до технического директора издания «Медуза». Мы задали Самату несколько вопросов, для того чтобы быстро прояснить, каково это — разрабатывать современный медиа-продукт для многомиллионной аудитории.

Текущее место работы
— Meduza.io

Должностные обязанности
— Отвечаю за всё техническое, что есть в Медузе.

/ фото ChrisDag CC

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

Здравствуйте, уважаемые читатели.

Сегодня мы хотели бы поговорить с вами о важном аспекте гибкого управления проектами, но не о чистом Agile, а о планировании проекта и итераций. Речь пойдет о жанре «Пользовательских историй», которым посвящена очень успешная на Западе книга Джеффа Паттона с предисловием Мартина Фаулера:



В статье, текст которой вас ждет под катом, мы перевели «User Story Mapping» как «визуализация функционала». Вариант взят из очень интересной книги Бориса Вольфсона "Гибкое управление проектами и продуктами", также выходившей в нашем издательстве.

Итак, автор статьи прочитал труд Паттона и решил, что так должен поступить каждый. Насколько убедительные примеры он привел — судить вам.

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

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

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

История дружбы двух компаний: «ТМ» и Redmadrobot началась во дворе… нашего офисного центра. Кроме шуток — офисы наших компаний находятся в одном здании и, даже несмотря на такую «близость», долгое время мы друг о друге лишь слышали.

До того самого момента, когда «Роботы» (так ребята называют себя сами) первыми вышли на связь и предложили прийти к ним в офис, познакомиться и пообщаться. Так сложилось, что наше «общее» знакомство сразу стало продуктивным — Boomburum рассказал, как правильно вести блог на Хабре, а после этого разработчики «ТМ» попали на пьянку в офис Redmadrobot. Так всё закрутилось, завертелось и в один определённый момент за столом остались только я, Максим и диктофон.

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

Автор: Евгений Ефимов
QA Lead, DataArt

Моряки, самолеты и корпорации

• Н.Н. Талеб и моряки.
• Абрахам Вальд и самолеты.
• Левитт и корпорации.

Существует понятие «систематическая ошибка выжившего». Оно встречается в книгах Талеба “The Black Swan. The Impact of the Highly Improbable” («Черный лебедь. Под знаком непредсказуемости» и “Fooled by Randomness: The Hidden Role of Chance in Life and in the Markets” («Одураченные случайностью. Скрытая роль Шанса на рынках и в Жизни»). Он описывает красивую картину, на ней древнегреческие моряки молятся богам во время шторма. Богам нравится, как они молятся? и поэтому моряки спасены. Шторм превращается в штиль или слабый ветер, корабль доплывает до берега, и все остаются целы. Когда спрашивают других моряков, как удалось доплыть, они тоже говорят: «Мы молимся богам и всегда доплываем». Проблема в том, что мы не можем спросить об этом моряков, которые утонули. Возможно, что они тоже молились, но не доплыли. И вообще дело было не в этом, а, т. к. в то время почти все моряки были религиозны, можно предположить, что молились все. И есть вероятность, что это не действует.
Вторая история — про математика и статистика Абрахама Вальда и про самолеты. Действие происходит во время Второй мировой войны. Британские бомбардировщики возвращаются на базу. Задача — понять, где и как укреплять самолеты, чтобы как можно больше возвращалось и как можно меньше падало. Они смотрят на самолеты, которые вернулись, и говорят, что необходимо укреплять наиболее поврежденные попаданиями части. Поскольку в них все время стреляют, мы их укрепим, и все пули улетят обратно во вражеский самолет и всех там перебьют.

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

Стивен Левитт написал интересную книгу «Фрикономика». Он выбрал стандартные книги из серии «10 шагов к успеху» и проанализировал две книги, где рассказывалось про корпорации, использовавшие нововведения, которые привели их к успеху. Эти книги были условно написаны в 2000 году, и корпорации, используя эти наработки, побеждали остальные компании. На момент, когда Левит их анализировал оказалось, что три четверти этих корпораций закрылись. Они оказались убыточными, потому что внешняя среда поменялась, а они не изменили подход к успеху. Соответственно, все эти истории успеха не всегда и не для всех работают.

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

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

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

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

Корпорация Microsoft запускает новый сервис — Planner. Он станет непосредственным конкурентом популярного таск-менеджера Trello. Сравнивая внешний вид и принцип работы двух сервисов, можно найти много общего.

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

Вступление

Здравствуйте, сегодня я расскажу вам о моём сервисе kanbanonrails.com, позволяющем создавать Канбан доски и интегрировать их с Github и Bitbucket.

Недавний стремительный взлёт основанного на децентрализованной платформе «Эфириум» проекта «The DAO (ДАО)» (в ходе запуска которого было собрано порядка 150 млн USD инвестиций), вызвал всеобщее воодушевление относительно концепции Децентрализованных Автономных Организаций. При этом для криптовалюты Dash существование в режиме ДАО — это уже “прошлогодний снег”. В этой переводной статье будут рассказаны подробности об этом.

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

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

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

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

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

У системы документооборота тоже может быть свой фундамент — технологическая платформа. Выбор платформы и принципов, на которых она построена, в буквальном смысле влияет на то, как СЭД будет дальше жить — ведь эти принципы и есть те самые “кирпичики”, которые обеспечивают ее устойчивость.

СЭД, представленные “коробочной” версией, практически все схожи по функциональности, поскольку представляют собой типовые решения, подходящие для большинства организаций. Однако, если документооборот организации отличается целым рядом особенностей, которые не в состоянии учесть ни одно “коробочное” решение, здесь не обойтись без конструктора: система должна предоставлять возможности для доработки.

Именно в таких случаях важен выбор платформенного решения. Однако, какой должна быть платформа, лежащая в основе будущей СЭД? Какие фундаментальные принципы должны лежать в ее основе? Мы выделили для себя три основных принципа, которыми должна обладать технологическая платформа системы электронного документооборота, чтобы обеспечить успешное развитие СЭД в будущем.

Эта статья — выражение моей личной боли. Кнопочные решения портят мне жизнь, я трачу время на споры и обоснования.

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

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

Для тех, кто любит смотреть, а не читать, есть видео и слайды.

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

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

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

В качестве примера можно рассмотреть ситуацию, когда требуется сократить срок сдачи проекта.

Вслед за компаниями Theranos, uBeam и Lending Club в скандальную историю попал еще один член клуба «единорогов» (стартапов с оценкой за $1 млрд) – платформа для фрилансеров Upwork, пишет сайт zerohedge.com. Последний квартальный отчет обрушил стоимость компании. Сейчас Upwork находится в свободном падении: первоначальные инвестиции в $15,8 млн, сделанные в 2012-2014 гг., теперь оцениваются примерно в $7,3 млн.

В то же время третий за последние два года генеральный директор увеличил комиссию для пользователей сервиса более, чем в два раза. По факту, они отменили фиксированную ставку в 10% и привязали ее к заработку. Теперь исполнитель, получающий менее 500 долларов за разовый заказ, отдаст сервису 20% его стоимости (плюс комиссия за транзакцию).

В свете того, что Мегамозг вновь воссоединился с Хабром, теперь можно ожидать, что аудитория обоих порталов также объединилась. Логично будет предположить, что Хабр будет привлекать большее внимание менеджеров, которым не чужд мир современных технологий. Поэтому наша команда SmartProgress решила подготовить статью на перепутье разработки и управления проектами.

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

Когда у нас надёжно заработала непрерывная интеграция на Jenkins и устоялись процессы выпуска релизов продукта, возникла мысль: а почему бы не перенять передовой опыт и не поставить в офисе свой электронный излучатель информации (information radiator): большой красивый экран, на котором автоматически отображаются происходящие с проектом процессы?



Мысль хорошая, но ведь это стоит денег и времени, т. е. того, чего никогда нет. Особенно сейчас. Особенно у маленьких компаний без бюджетов на всевозможные вспомогательные цели. Сделать всё предстояло за «пять копеек» и за «пять минут» — и вот как я с этим [частично] справился.