Управление проектами *

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

Все началось с того, что сервер статистики контактного центра заказчика (на тот момент ещё потенциального) сбросил все пользовательские сессии и перестал отвечать на запросы. Соответственно к нему подкатили тележку с монитором и перезагрузили. Это обычно надо делать раз в 90 дней по инструкции от вендора, но тут это не делалось больше 500 дней. В общем, сервер отметил юбилей аптайма. 

Дальше быстро выяснилось, что на рестарте посыпалась база и пропали конфиги. Но главное, что сервер стартанул, бэкапы куда-то писались. Всё хорошо, железо работает, диски в порядке, надо просто накатить бэкап. 

Но после накатывания бэкапа система просто легла. 

В этот момент нас позвали отмечать день рождения сервера. Без него не работала балансировка нагрузки на операторов внутри КЦ. 

1. Как провести собрание. И нет, не болтать больше всех на собрании, а именно провести его.
2. Как написать проектную документацию, получить отзывы и довести ее до решения в разумные сроки
3. Как наставлять «младшего» коллегу по команде, инженера в середине карьеры, нового менеджера, которому нужен технический совет
4. Как порадовать старшего менеджера, который хочет поговорить о технических вещах, которых он на самом деле не понимает, не закатывая глаза и не заставляя его чувствовать себя глупо
5. Как объяснить техническую концепцию за закрытыми дверями высокопоставленному лицу, слишком смущенному, чтобы открыто признать, что он ее не понимает
6. Как убедить другую команду использовать ваше решение вместо написания собственного
7. Как заставить другого инженера сделать что-то для вас, попросив о помощи таким образом, чтобы он почувствовал, что его ценят
8. Как вести проект, даже если вы не менеджерите никем из людей, работающих над ним
9. Как заставить других инженеров прислушиваться к вашим идеям, не заставляя их чувствовать угрозу
10. Как прислушиваться к идеям других инженеров, не чувствуя угрозы

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

Последние пять лет я работаю в аутсорсинге, поэтому часто занимаюсь запуском новых продуктов. Чаще всего первый шаг - создание так называемого MVP (minimum viable product).

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

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

Сегодня я расскажу, как мы вышли из этого треугольника (мое выступление на эту тему).

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

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

Поглядим, чему же программисты могут научиться у каменщика дяди Толи.

Phabricator — полностью открытый и бесплатный набор веб-инструментов для совместной разработки (конкурирует с инструментами типа azure.devops, atlassian, GitLab) вышедший из Facebook и поддерживаемый все эти годы бывшим разработчиком FB Эваном Пристли.

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

Если вам, как и мне, интересно покопаться в причинах провала качественного продукта и помечтать о его возрождении - прошу под кат.

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

Когда начали строить новый красивый бизнес-центр недалеко от главной улицы города, мы с подругой были выпускницами престижного вуза и поступали в аспирантуру. Она задрала голову на этажи из стекла, бетона и металла и спросила: «Хотела бы работать в таком здании, в огромной корпорации?» «Ага, может когда-то», — кивнула я, думая об одной лишь карьере учёного. Но у жизни на моё «ага» были свои планы: я прошла и через корпорации, и через науку, и через вуз — и в итоге оказалась в малом бизнесе. В самой комфортной точке на протяжении моей карьеры. Здание достроено, в нём — межгалактические корпорации, но я ни за что не пойду туда работать: у меня есть веские причины сделать такой выбор.

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

Я постаралась систематизировать в этой статье свой опыт подбора множества дизайнеров на проекты различной сложности: от пакета баннеров, лэндинга до интерфейса No-code платформы без ТЗ. Материал будет полезен тем, кто слабо разбирается в дизайне, впервые подбирает дизайнера на проект или получает проекты не того качества, которого хотелось бы.  

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

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

Всё это я проговаривал в подкасте Кода Кода.

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

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

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

Вы можете посмотреть видеоверсию статьи, либо прочитать текстовый материал...

Статья для менеджеров, которым необходимо вести управление проектами в изменчивом мире Agile. Поделюсь опытом использования двух приложений Jira Roadmap и Structure Gantt.

Привет Хабр!

В командах разработки трекеры задач и IDE редко существуют друг без друга. Поэтому мы решили существенно «проапгрейдить» плагин YouTrack для IDE на платформе IntelliJ. Плагин интегрируется с вашими любимыми IDE от JetBrains — AppCode, CLion, DataGrip, GoLand, IntelliJ IDEA, PhpStorm, PyCharm, Rider, RubyMine и WebStorm, а также с Android Studio — и дает вам доступ ко всем задачам и уведомлениям прямо из IDE. Также с помощью плагина стало удобнее вести учет времени. Для него появилось несколько режимов — теперь вы сможете сосредоточиться на написании кода и не тратить время на отчетность. Ниже расскажу обо всем подробнее.​

В 2018-м в Skyeng появились онлайн-занятия математикой. Так мы столкнулись с тем, что наша платформа, адаптированная под устный английский, не очень подходила для письменных занятий с дробями, формулами и геометрическими фигурами.

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

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

Но по каким-то невнятным физиологическим причинам этот ценный навык доверия проверенным людям стёрся во взрослых мозгах. Иначе я никак не могу объяснить, почему люди задают в социальных сетях вопрос: «Какая у вас CRM / ECM / ERP / PM / BI…?» и принимают решение на основе советов из треда. Вопрошающий ничего не знает ни о компании, ни о ложности аккаунта, ни о том, кто перед ним — опытный предприниматель или новоиспеченный дилер облачной CRM, который ходит по таким тредам, чтобы пропихнуть свои услуги. А потом уже мы слышим: «Выбрал CRM X, а она мне не подошла. А вы можете помочь?» 

Введение

В 2021 наметился тренд: повышенный спрос на бизнес-аналитиков. Практически каждый проект стремится заполучить в свои ряды специалиста с такой ролью. При этом вакансии с примерно одинаковым описанием должностных обязанностей поражают многообразием названий: requirement specialist, business analyst, system analyst, (proxy) product owner, product manager. Меня зовут Святослав Щербатюк, я сотрудничаю с ЕРАМ в роли ведущего бизнес-аналитика. В этом материале предлагаю порассуждать, почему сложилась такая ситуация, отличаются ли эти роли между собой и если да, то чем.