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

image

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

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

Ожидания

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

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

Рассмотрим одно из подразделений Яндекс.Маркета. Оно довольно крупное — 85 человек. Внутри подразделения есть несколько команд. Команды либо занимаются функциональными частями Маркета, либо решают какую-то большую пользовательскую задачу. Вот одна из них: изменить сам сервис Яндекс.Маркет и интернет-торговлю в регионах так, чтобы местным пользователям стало удобнее решать свои проблемы.

С чего командам начать? Как объяснить всем вокруг, почему мы делаем одно, а не другое? Как донести до каждого инженера, зачем он занимается своей текущей задачей? Как вкладывать силы в то, что действительно улучшит мир вокруг, и не тратить время на то, что не нужно? Как сделать работу команд прозрачной друг для друга?

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

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

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

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

Так что в списке «Самые неразвивающиеся компаниии» остаются только франчайзи 1С. Там работает куча прекрасных людей, но то ли среда такая, то ли место проклятое — с ними что-то не так.

Они думают только о сегодняшнем дне. Возможно, виновата жесткая привязка к одному вендору, который разрабатывает и фреймворк, и прикладные решения. Никто же в здравом уме не будет в 21 веке строить долгосрочный бизнес, завязанный на один язык программирования, одну среду разработки, один рынок? А вот ковать железо, пока горячо — пожалуйста. Когда остынет, тогда и можно будет задуматься о чем-то серьезном.

Но мне, почему-то, кажется, что не все потеряно. Можно сделать лучше.Читать полностью »

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

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

Как поделить архитектуру и реализацию и не поругаться - 1

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

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

От переводчика: Привет, Хабр! Да, это очередная статья о преимуществах и недостатках монорепозиториев. Собирался написать свою статью о том, как мы используем монорепозиторий, как мы переходили с maven на bazel и что из этого получилось. Но пока собирался с мыслями, вышла отличная статья от разработчика из Lyft, которую я и решил для вас перевести. Обещаю опубликовать свои дополнения к статье, а также опыт с bazel в виде продолжения.

Мы в Новом 2019 году, и я настроен на еще одну дискуссию о преимуществах (или отсутствии таковых) в хранении всего исходного кода организации в «Монорепозитории». Для тех из вас, кто не знаком с этим подходом, идея состоит в том, чтобы хранить весь исходный код в едином репозитории системы контроля версий. Альтернатива, конечно, заключается в том, чтобы хранить исходный код в нескольких независимых репозиториях, разделяя их обычно по границе сервисов/приложений/библиотек.
В данном посте я буду называть такой подход «полирепозиторий».
Читать полностью »

Ольга Стратанович, Program Director в ProductSense и Chief Product Officer в «Киноплан», рассказала о ключевых отличиях в мышлении и навыках менеджера продукта и менеджера проекта.

Продакт vs. Проджект: чем отличаются профессии, которые часто путают - 1

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

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

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

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

История одного проекта: когда в команде нет senior developer - 1

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

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

Flowcon, или Флакон – методика управления, в том числе – задачами. Потоком, проектом, разработкой, рутинными функциями, регуляркой и т.д.

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

Лучше всего, мне кажется, в виде истории изложить, потому что рождение флакона тесно связано с моей, с позволения сказать, карьерой. Так и поступлю. Погнали.Читать полностью »

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

Цена изменений: во сколько на самом деле обойдется переработка кода - 1

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

Модель оценки объема работ

Вы можете свести в один список все фичи своего приложения, а после оценить этапы и приблизительное время их переработки. Большинство именно так и поступает перед тем, как приступить к работе. Но почему тогда на практике выходит, что подобные проекты занимают в 4, 8 или даже 10 раз больше времени, чем разработчики заложили на старте?

Читайте также

Публикация о временных затратах на написание программного кода, которая пригодится при оценке объема работ: «Правило 10:1 в программировании и писательстве»

Есть три ключевых фактора, которые существенно растягивают процесс. И обычно при оценке затрат их игнорируют. Речь идет о
1) необходимости наверстать разницу между уровнями текущего и нового приложений,
2) объеме непредусмотренных изменений,
3) улучшениях, которые придется сделать, чтобы пользователи захотели перейти на новое приложение.

Цена изменений: во сколько на самом деле обойдется переработка кода - 2

Сокращение разницы

Первый фактор — новому приложению необходимо догнать текущее.Читать полностью »

Ozon.ru — почти ровесник Рунета, в свои 20 лет мы старше многих наших клиентов. Из книжного интернет-магазина компания выросла в e-commerce платформу, которая объединяет инфраструктуру fulfillment-центров и логистики, веб и мобильные приложения, выдерживает и набеги десятков миллионов пользователей во время распродаж, и атаки интернет-мошенников.

OZON изнутри: feels like a startup - 1

В этом посте мы немного расскажем про себя: о том, как перестраиваем и развиваем платформу, одновременно обслуживая 1,2 млн пользователей ежедневно. А заодно покажем офис, где трудится IT-лаборатория OZON, ну и пару шикарных видов из его окон.
Читать полностью »


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