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

Почему у одних людей ничего не получается, а другие доводят любое дело до конца? В чем разница между хорошими и выдающимися профессионалами? Где грань между деспотизмом и верой в результат? Ну и что объединяет прекрасных продакт-менеджеров в клуб настоящих профессионалов? Под катом прекрасный рассказ Лоуренса Рипшера.

Жил был проектный менеджер. Работал он в банке. Поручили сделать ему внешний продукт для банка этого. Нужно было менеджеру найти удаленную команду разработки, которая сделает его ему. Команду разработки он нашел, ТЗ написал. Начали они работать вместе. Работа в первое время шла хорошо. Спринты закрывались в срок, качество не страдало.

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

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

1. Что такое качество в разработке ПО?
2. Во сколько нам обходится некачественное ПО?
3. Кто отвечает за качество?

Для меня поводом задаться этими вопросами стала встреча с компанией в которой 3 месяца в году всё подразделение разработки (около сотни человек), занято устранением ошибок и дефектов, а остальные 9 месяцев они пишут ошибки софт для Заказчиков.

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

Автор — Джейсон Фрид, основатель и исполнительный директор Basecamp.

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

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

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

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

Я уже писал о моделировании при помощи IDEF0 (Знакомство с нотацией IDEF0 и пример использования), об организации работы склада и работе с клиентами от лида до сделки (Внедрение CRM. От регистрации лида до закрытия сделки. Кейс и пояснения), о системе Bizagi (Bizagi. Описание. Пример). И везде я использовал при пояснении примеров и практических решений нотации бизнес-процессов.

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

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

Моя первая работа в области разработки ПО заключалась в программировании на С++ для компании J.D. Edwards, которая сейчас является частью Oracle. Я проработал там с 1996 по 2000 год. Она настолько отличается от любой работы, на которой я был с того времени, с настолько разных сторон, что я всегда отношу ее к короткой “доинтернетной” фазе моей карьеры. Но есть такой момент – команда, в которой я работал, была самой разнообразной из тех, в которых я работал. А может даже из тех, с которыми лишь приходилось иметь дело, в рамках всей нашей отрасли.

Почему? Думаю, у меня есть ответ.

Культура J.D. Edwards и стандарты рабочего пространства были заимствованы напрямую из IBM. Пиджак и галстук обязательны для мужчин. Каждый день. Можно было оставить пиджак на спинке стула в кубикле всю неделю, уезжать домой и приезжать обратно в рубашке, но если ты не забрал пиджак домой на выходные и не менял его каждую неделю, тебе бы указали на это. Если ты начал появляться на работе в 9 вместо 8:30, на это обязательно бы указали. Ништяки? Бесплатная газировка. Пятницы в стиле кэжуал неохотно вводились лишь под давлением интернет бума, потому что иначе становилось труднее нанимать людей. Я любил мою работу и ненавидел дресс-код и режим.

Понятие HumanOps родилось в Server Density в результате накопления значительного опыта работы по мониторингу компьютерных систем и, соответственно, пребывания команды в состоянии постоянной готовности. В первые годы существования компании я долгое время был на связи в режиме 24/7. Однако по мере роста команды мы внедряли процессы и политики, целью которых было распределение нагрузки и снижение негативного влияния случаев, когда сотрудников отрывают от текущей работы или звонят во внеурочное время, в том числе и ночью.

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

Мы надеемся, что аналогично практикам DevOps, ускоряющим развертывание, приносящим новые инструменты, а также объединяющим команды разработки и эксплуатации, HumanOps поможет организациям в освоении более «человечного» подхода к построению систем и работе с ними.

Под катом вы найдете 12 принципов HumanOps и описание их работы на примере Server Density.

Привет, Хабр! Сегодня мы расскажем о том, как разные команды в JetBrains “готовят” Agile и работают с Agile досками.

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

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

Привет, Хабр! Меня зовут Алексей Рыбак, я – глава разработки в Badoo. В феврале в нашем московском офисе Badoo проходил Techleads-митап, где я рассказывал про наш процесс Performance Review. Эта статья написана по мотивам моего выступления.

Outcome-driven innovation — это фреймворк, в основе которого приоритизация планов разработки компании на основе задач, для которых клиенты эти продукты покупают — Jobs to be done. Фреймворк дает хорошее методическое описание и обоснование идей и практик, которые каждый product owner, по идее, и так применяет или должен применять, но обычно — интуитивно и на менее системном уровне.

На Codefest 2017 Аркадий Рушкевич, product-manager Wrike, рассказал о собственном опыте использования Jobs to be done и ODI — как и зачем Wrike начал заниматься этим, какие плюсы и минусы мы увидели, чего добились.

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

Как и обещали в предыдущем выпуске (с советами от разработчиков), публикуем новую серию видео-интервью с крупнейшей русскоязычной конференции DevGAMM.

Метапоисковик — это не так просто, как кажется. Почему мы не можем подгружать сразу все туры? Почему так часто меняется цена? Кто виноват, когда тур “ушёл”, и как выкрутиться перед клиентом?

Об этих и других проблемах и багах сайта Travelata.ru я рассказал в первой части. Продолжаем публичную порку самих же себя.

Отельная страница

Когда открывается серп, направляется запрос в кеш, который хранится от 15 минут до нескольких часов. В момент открытия отельной страницы, если на отель из кеша пришло менее 3 туров, к ТО отправляется новый запрос на поиск по названию отеля. И могут приехать новые цены. Актуальные.

Почему вообще приходится так часто отправлять запросы к ТО?

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

Вторая причина — туры просто быстро раскупают.

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

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

Пройдёмся по воронке.

---

Главная страница

Представим, что пользователь попал к нам случайно, и ранее он покупал туры только в турагентстве у метро. Первое, что он делает — пытается найти форму завки. А у нас её нет, есть только кнопка “Подберите мне тур”, которая не сильно заметна, да и показывается не на всех страницах сайта.

Платон Бегун, руководитель направления контактных центров CTI

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

В определенный момент развития компании руководство ИТ-подразделения может столкнуться с ситуацией, когда решение инцидентов занимает слишком много времени, пользователи оказываются недовольны предоставляемыми услугами, а внутренняя организация работы представляет собой полный хаос. Одним из вариантов решения этих проблем является внедрение ITSM (Information Technology Service Management). В рамках этого поста, которым мы решили открыть свой блог на Хабре, мы поговорим о том, что такое ITSM, и рассмотрим некоторые возможности платформы ServiceNow.

Небезызвестный Джейсон Фрайд из Basecamp разразился дискуссионным эссе о работе, вызвавшем ожесточенные споры на зарубежных сайтах. Мы в Alconost поспешили его перевести.

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

Давайте будем честными.

Как возникла необходимость отойти от классической Каскадной Модели жизненного цикла разработки

В 2009 году мне предложили выбрать и реализовать один из «гиблых» проектов. Приставку «Гиблый» каждый получил за то, что раньше за них уже пробовали браться, но ничего не вышло.

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

Большой пример: только оказавшись под санкциями и цене нефти в 50 долларов за баррель (против 110 ранее) руководство страны перешло от рассуждений и неспешных телодвижений к активным действиям по развитию высокотехнологичной экономики.

Так и один из моих Заказчиков созрел и я взялся сделать для него проект по разработке нового функционального модуля Корпоративной Информационной Системы (ERP-системы), который должен был добавить 400 новых пользователей системе и обеспечить проверку 40 000 ипотечных кредитов в год.