Составили документ по которому можно выбрать подрядчика на разработку сайта или мобильной приложения. Для удобства работы, мы разделили чек-лист на несколько блоков: требования к подрядчику, требования к продукту и требования к продвижению.
Управление разработкой *
Планирование, отслеживание и контроль
Как я собрал красивое ведро для гидропоники
Несколько лет назад я писал пост о том, как вырастить на гидропонике крайне острый Trinidad Scorpion CARDI. Он, при его живительных 1.2 миллионах единиц Сковилла, на неподготовленных перцеедов производит впечатление эквивалентное облизыванию паяльника.
Пока Монстр плодоносил и радовал в течение нескольких лет, я продумывал более удобный вариант гидропонной установки, который было бы не стыдно показывать в приличном интерьере гостям. Классический вариант “юного гидропониста” из канализационных труб, алюминиевого скотча и вороха булькающих трубочек был с негодованием забракован женой. Я разработал и протестировал несколько прототипов с 3D-печатными элементами, но потом проект был поставлен на паузу.
Окончательно доделать его получилось после того, как внезапно выяснилось, что коллеги тоже фанаты острого. Мы собрались в нашей виртуальной “курилке”, запилили проект со всеми положенными milestone в Asana и начали тестировать. Садитесь поудобнее, сегодня будет лонгрид-оффтопик, про то, как толпа DevOPS из WiseOPS пилила совместный хобби проект для украшения офиса. Да, мы заняты не только работой) А еще я поделюсь подробной инструкцией и файлами для 3D-печати.
Сегодня расскажу про то, как правильно утопить растение, спроектировать прототип и выйти в релиз, даже если твои тестеры очень сильные люди.
Как проанализировать риски: 4 шага
Оценка потенциальных рисков и их влияния на бизнес-операции играет ключевую роль в обеспечении успеха проектов и стратегий организации. Риск-менеджеры проводят анализ, используя различные методы и расчеты, чтобы определить вероятность возникновения рисков и разработать планы реагирования для минимизации их воздействия. Понимание основных принципов анализа рисков и методов контроля и управления ими помогает обеспечить успешное выполнение проектов и достижение целей компании. В данной статье мы рассмотрим суть анализа рисков, перечислим преимущества и сферы применения данного подхода, а также представим шаги, необходимые для эффективного анализа рисков в бизнесе.
Может ли мобильный-разработчик стать CTO?
Да, может. На этом статью можно было бы закончить. Спасибо, что дочитали до конца, приходите поделиться своим опытом в комментариях.
Если серьёзно, карьера мобильного разработчика, который хочет вырасти в большого руководителя, может складываться по-разному. Например, мой путь начался в 2013 году, и за это время я успел поработать и в маленьких стартапах, и в больших корпорациях. Сейчас я Director of Engineering в Яндекс Go. Последние шесть лет я управляю разными командами разного размера: от 5 до 200+ человек.
В этой статье я хочу рассказать, какие есть пути развития в мобильной разработке, что делать, если ты уже тимлид, кто такие крутые Individual Contributors (топовые разработчики) и как стать одним из них. Обо всём этом читайте под катом: попробуем разобраться, как расти и куда это может завести.
Истории
Что мы делаем, когда у нас заказывают аналитику без нормальных формулировок
Сюр?
Сюр. Но встречается на каждом шагу.
Вопрос решается с помощью Self-service, который даёт всем желающим возможность работать в базе данных на низком уровне. И он может удовлетворить как айтишников, с которых снимается уйма хлопот, так и бизнес-подразделения, которые теперь могут получать все необходимые расчёты ровно в том виде, который их полностью устраивает. То есть это отличный способ дать бизнесу возможность быстро находить ответы на свои вопросы.
Legacy: поддерживать нельзя переписать
Легаси — реальность любого программиста. Объясняем, как софт становится легаси и почему это нормально, а также какие существуют плюсы при работе с легаси. Не всегда стоит относиться к легаси как к проклятию, стоит взглянуть на него как на естественный этап жизненного цикла программного обеспечения. Меня зовут Алексей Рузин, я уже 27 лет работаю и знаю, как работать с легаси.
«Легаси» — это слово, которым программисты пугают друг друга (и менеджеров). Оно означает устаревший софт, работать с которым обычно сложно и/или неприятно по причине небольшого «выхлопа» в пересчете на вкладываемые усилия. В целом, словом «легаси» можно назвать любой «код», который сложно поддерживать. И чем сложнее, тем он более «легаси».
Сегодня расскажем, откуда оно берется, как удерживать его “в рамках” и чем оно может быть полезно для начинающих специалистов.
Ивент шторминг (Event Storming) при работе над игровыми проектами
Ивент шторминг (Event Storming) — это отличный способ разложить продукт по полочкам, понять, как он работает (или должен работать), а также донести это до всех участников команды, чтобы картинка в разных головах была одинаковой (что сильно упростить разработку и поможет избежать ошибок и недопониманий).
На моей практике Event Storming успешно использовался в проектировании игр, именно об этом я расскажу в данной статье.
У тимлида есть только путь: как и зачем расти выше по карьере
Всем привет! Меня зовут Сергей Яныкин, я менеджер разработки в СберМаркете — управляю Unit-лидами, которые, в свою очередь, управляют тимлидами разработки.
Нам постоянно приходится выбирать: где учиться, на каком стеке писать, в какой компании работать. Если вы открыли эту статью — возможно, и вы сейчас стоите перед карьерным выбором: расти ли дальше вертикально, и если да — то как.
Я и сам проходил через это.В статье я покажу плюсы и минусы вертикального роста и расскажу, что качать, куда и как расти и что делать, если вас не повышают.
Мир, дружба, дедлайн: как избежать конфликтов в разработке и сохранить команду
Начну, пожалуй, с противоречивого заявления. Конфликт — это хорошо. Но хорошо это лишь в том случае, когда все стороны конфликта стремятся к его разрешению с учетом интересов каждого участника. И, спешу вас обрадовать, большинство видов конфликтов вполне себе разрешимы, главное, во всем разобраться и найти компромисс.
В этой статье тему конфликтов мне бы хотелось сузить до конфликтов на работе, а именно — в разработке. А если вы разработчик, «бодаться» с коллегами в рабочем процессе, скорее всего, вам приходится довольно часто. Программисты и тестировщики, менеджеры и заказчики — это, можно сказать, архетипичные модели.
Давайте разбираться!
Руководство по интеграции Flowable с Spring Boot
BPMN — это язык визуального моделирования бизнес-процессов, использующий графические блок-схемы. Это открытый стандарт, созданный консорциумом Object Management Group (OMG).
Процессный движок Flowable позволяет разворачивать процессы в соответствии с международным отраслевым стандартом BPMN 2.0. Каждый процесс BPM представляет собой последовательность объектов, связанных с действиями и имеющих стартовое и конечное события.
BPMN используется для автоматизации бизнеса — например, в управлении пользовательским/клиентским опытом или управлении мероприятиями. Он упрощает и ускоряет разработку, уменьшая количество ошибок.
Разрабатываем бизнес-приложения на основе процессов жизненного цикла бизнес-систем
Привет, я Алекс Степанов – независимый разработчик бизнес-приложений. В настоящее время я также сотрудничаю в роли ИТ-аналитика с топовой федеральной розничной сетью и консультирую их ИТ-менеджеров по технологиям интеграции и функциональной разработки, написанию ТЗ. Но то, о чём я сообщу далее, было получено мною задолго до этого сотрудничества.
Если вам приходилось проектировать ИТ-решения для бизнеса, то никогда не задавались такими вопросами? - Конечно ли вообще пространство вариантов создаваемых ИТ-решений? - И если да, то что определяет границы этого пространства? - И из каких областей, это пространство может состоять? Или говоря другими словами: то, что нашей проектной команде предстоит сделать, имеет вообще объективные разумные границы и счетное количество вариантов реализации? Эти вопросы и ответы на них отделяют ИТ, как ремесло и бизнес, от ИТ, как инженерия и наука. В данной статье я решил поделить с вами некоторой частью своей системы знаний…
Когда я участвовал в проектах разработки, внедрения и сопровождения бизнес-приложений в роли консультанта, аналитика/проектировщика, программиста/кодера и даже специалиста техподдержки, то часто чувствовал дискомфорт, связанный со множеством проектных и технических неопределенностей. В основном это происходило на этапе обработки исходных требований и формирования замысла (образа) ИТ-решения и на этапе его проектирования. Это самые ответственные этапы, ошибка на которых может привести к кратному превышению затрат и времени ИТ-проекта. Корень этих неопределенностей в том, что понять, чего на самом деле хотят бизнес-заказчики часто непросто, а не поняв это достаточно глубоко, возникает целое поле альтернатив, выбрать из которого что-то одно наиболее подходящее еще сложнее.
Неидеальный спринт
Эта публикация вдохновлена одной из многочисленных презентаций о том, как планировать спринт в разработке, коих за свою жизнь я видел очень немало. И все они похожи одна на другую, как однояйцевые близнецы - всегда очень красивые рисунки и выверенный текст типа «тут у нас аналитика, вот разработка и тестирование, двухнедельный спринт, в конце спринта все задачи закрыты, руководство в восторге, заказчик счастлив». Я же хотел бы показать реальность такой, какая она есть.
Кадровая текучка в ИТ — мнения HR-партнеров компаний SSP SOFT и Softorium
Какие айтишники чаще меняют работу и почему, как текучка кадров влияет на работу в командах и что с этим делать? Евгения Забелина, HR бизнес-партнёр SSP SOFT обсудила эту тему с Анной Сабадаш, управляющим партнёром Softorium. Ситуация в разных сферах ИТ может разниться, в данном случае разговор идет о сфере разработки заказного ПО.
Ближайшие события
Рулетка онбординга: ежедневно удаляем аккаунты сотрудников
Я большой поклонник автоматизированных тестов и достаточно дисциплинированный их автор. Проектирование ПО крайне сложно реализовать функционально корректно и ещё сложнее избежать регрессии в дальнейшем. Как сказал Майкл Фезерс, «легаси-код — это весь код, у которого нет тестов».
Некоторые вещи, например, конечные точки серверов, схемы баз данных и компоненты библиотек UI тестировать очень просто.
Другие вещи тестировать сложнее, например, конечные точки, вызывающие сторонние API, веб-страницы на React со сложными состояниями и асинхронные задачи, требующие детализированных записей баз данных. Airbnb мне было сложно тестировать письма со сбросом паролей, потому что отправка электронной почты выполнялась через аутсорсный сервис.
Но такая функциональность всё равно заслуживает тестов, и на то есть две причины. Во-первых, всё равно важно, чтобы она не регрессировала, из-за их сложности вероятность регрессии велика. Во-вторых, тестирование сложных фич часто заставляет инженеров проектировать фичу таким образом, чтобы её можно было тестировать. Если вводить тесты ещё на ранних этапах разработки, это может мотивировать к проектированию более узких интерфейсов и снижению связанности, а значит, в долговременной перспективе приводит к повышению качества кодовой базы.
Как организовать межкомандную работу в трекере задач METEOR
Сегодня мы поделимся, как организовать межкомандную работу в трекере, какие трудности сопряжены с этим, и какие бывают способы организации такого взаимодействия.
Важно заметить. Если вы используете трекер без ролей и прав, или если ваши пользователи из разных команд видят задачи друг друга и могут с ними работать и вас это устраивает, то это статья не для вас.
Статья будет полезна тем, кто разграничивает права доступа по командам, проектам и сталкивается с вопросами корректной организации совместной работы разных команд друг с другом.
Основы тайм-менеджмента: ежедневное планирование в календаре. Как планироваться, чтобы не испытывать боль. +Регламент
Ведение календаря при работе в команде – мастхэв. Каждый участник может поставить встречу в свободный слот, закинуть задачу с описанием, ознакомиться с задачами, которые вы выполняли. Запланировать долгосрочные задачи.
Для того, чтобы ведение календаря повышало эффективность сотрудников, а не вызывало боль, мы составили регламент. Делимся им в материале.
Нужен ли удаленной команде менеджер?
Обсуждая удаленку, мы часто говорим о том, что комфортно в таком режиме работается людям с высоким уровнем самостоятельности - тем, кто может сам спланировать время, мотивировать себя делать задачи (да и в целом понимает, что удаленка - это не фриланс, а “фриленд”).
Но если мы набираем целую команду таких самостоятельных, нужен ли им еще и менеджер? Не справятся ли они сами, просто разбирая задачи из Jira?
В этой статье поговорим о том, чем на мой взгляд должен заниматься руководитель команды на удаленке. Сразу отмечу, что здесь нет никаких ноу-хау, я просто собрал наработанный за много лет опыт и выделил несколько самых важных пунктов.
Как тимлиду оценить «КПД разработки». 4 работающих способа — без хрустального шара и гадания на кофейной гуще
Привет, Хабр! Я Аня Анциферова, продакт «Цифрового вагона». Я уже рассказывала о том, зачем ПГК пошли в разработку и какие продукты мы делаем. Несмотря на то, что сейчас у ПГК существует «дочка» — ПГК Диджитал, и там трудится порядка 400 человек, мы — не ИТ-гигант. А это значит, что каждый проект, за который мы беремся, и даже каждую фичу, которую дорабатываем, мы должны оценить на предмет эффективности. И доказать, почему разработка оправдана и целесообразна. Сегодня расскажу о том, как такую базовую оценку может провести тимлид.
Когда ваши требования готовы?
Бизнес-требования, техническое задание - это важный результат работы аналитиков. Поэтому разумным выглядит вопрос, когда считать требования готовыми, как ориентир качества для аналитика?
На этот счёт есть рассуждения на тему полноты, непротиворечивости, реализуемости, понятности для команды, согласованности со стейкхолдерами. Все необходимые артефакты для разработки, конечно, должны быть собраны и правильно оформлены. Фактически, это рассуждения о качестве требований: требования готовы, когда они удовлетворяют критериям готовности (критериям качества).
Как менять команды, не увольняясь из компании. Культура горизонтальной мобильности в Контуре
Меня зовут Настя Миронова, я менеджер разработки в Контуре и уже около двух лет руковожу командой Рейнджеров – это разработчики без своего продукта, такие мобильные инженеры. Команда появилась в конце 2020 года, и за это время мы постоянно исследуем, чем можем помочь проектам компании, как делать это еще лучше, и как вырастить или найти ребят, постоянно готовых к вызовам.
Думаем мы не в одиночку – в компании развиты механизмы и практики горизонтальной мобильности, которые помогают в переходах между продуктами, командами и даже ролями.
Об этом и расскажу в статье с примерами коллег.
Вклад авторов
nmivan 2664.0romas1982 1226.0semen_grinshtein 917.2kesn 624.0fillpackart 604.0m1rko 595.2ru_vds 573.2alizar 511.2olegbunin 482.0uyga 471.0