В этой статье я расскажу, как делал свой проект социальной сети для сферы искусства от идеи до релиза. Расскажу о технической части, о мотивации и самоорганизации, какими инструментами пользуюсь в процессе разработки, о проблемах в работе со сферой искусства, с которыми я столкнулся почти сразу после запуска. Проект пережил реинкарнацию, т.е. был первый вариант, который я забросил и финальный, второй, который ушел в релиз.Читать полностью »
В сфере управления людьми (куда многие из нас, айтишников, зачастую приходят внезапно), существует масса инструментов и подходов. Некоторые из них базовые, другие — идут следом. Но так или иначе огромное количество начинающих менеджеров открывают для себя инструментарий управления методом проб и ошибок.
Делегирование — один из базовых инструментов руководителя, о котором большинство знает. Но обращаются к нему часто слишком поздно, считая, что «ещё не пришло время делегировать — других дел полно». К сожалению, это может привести к не очень хорошим результатам.
В статье я расскажу, что такое делегирование, зачем оно нужно и когда надо начинать делегировать, как делегировать правильно и где можно наломать дров, как это всё соотносится с ситуационным менеджментом и как необходимо действовать. В конце я поделюсь собственным ноу-хау в области делегирования, надеюсь, что каждому читателю это будет полезно.
Добро пожаловать под кат!
Читать полностью »
Я работаю фронтенд-разработчиком около двух лет, участвовал в создании самых разных проектов. Один из выученных мной уроков: взаимодействие между разными группами разработчиков, объединенных одной целью, но имеющих различные задачи и степень ответственности, — дело непростое.
Советуясь с другими участниками команды, дизайнерами и разработчиками, я создал цикл создания сайтов, предназначенный для небольших команд (5–15 человек). В него включены такие инструменты, как Confluence, Jira, Airtable и Abstract. В этой статье я поделюсь особенностями организации рабочего процесса.
Читать полностью »
SCRUM стал настолько популярен, что сейчас его пытаются внедрять практически везде. В больших компаниях иногда получается так, что SCRUM внедряют ради отчетности, или для того, чтобы быть “прогрессивным” и “модным”. В результате ситуация, что вроде как ответственный менеджер поставил себе очередную галочку, мол, надо было внедрить методологию — внедрил, молодец, но при этом вместо каких-то качественных улучшений на выходе оказывается так называемый «Zombie SCRUM». Это когда формально фреймворк внедрен, но по нему никто нормально не работает. Отсюда и название.
Меня зовут Олег Егоркин, я agile коуч в Ростелекоме, и в этом посте я расскажу, почему «зомби-скрам» вообще возникает, как этого избежать и как убедиться, что в компании все готово к запуску скрам-команды.
Читать полностью »
Некоторое время назад, я перешел из компании, которая жила в мире жесткого Waterfall и суровых планов в MS Project на несколько тысяч строк, в компанию, которая живет в мире Agile — ценности, которую несут продукты уделяется больше внимания чем следованию плану, фокус в разработке сделан на скорость и качество, разработка здесь идет итеративно, для помощи командам есть коучи и скрам-мастера, MS Project используется крайне редко, а про Oracle Primavera никто и не слышал.
Не то что бы для меня это было в новинку, я и раньше работал в компании, которая активно использовала лучшие практики из Scrum и XP, но на таком высоком уровне опыта у меня не было. Тогда я задумался о том, как бы мне прокачаться в гибких методологиях, а также, как понять насколько ты прокачан? После беглого изучения вопроса, я и узнал о том, что в мире Agile, кроме специализированных курсов существуют еще и сертификации — компании, которые задают тренд на рынке, проводят специальные обучение и тесты, по результатам которых можно примерно сказать, какая квалификация есть (или нет) у того или иного специалиста.
Ощущения смерти, одиночества, в то же время безумная жажда к жизни… Вы могли бы подумать, что мы решили устроить лекцию по экспрессионизму и погрузить вас в творчество Мунка. Но нет. Все эти этапы ты переживаешь в момент, когда видишь, что твой технический долг скоро столкнёт твою компанию в бездну кризиса.
Сейчас, на пике экономического цикла в такой горячей отрасли как разработка ПО не принято считать деньги. Зачастую этот процесс в принципе позиционируется как творческая деятельность, где не надо ничего обосновывать, а художнику виднее, что и как писать. В частности, на тему юнит-тестов и TDD ведется много споров, но, к сожалению, все они скатываются к бездоказательным заявлениям и эмоциональным выпадам, подтверждаемым пруфами на удачно подобранные статьи и книги методологистов, зарабатывающих на консультациях и продажах тренингов, которые, в свою очередь, не содержат абсолютно никакой статистики или расчетов, либо, напротив, к огульным обвинениям в смузихлебстве и прочих грехах юности.
Мы продолжаем делиться внутренней кухней WebCanape и выдавать все наши самые страшные тайны. В прошлый раз я рассказывал, как мы разработали CRM для SEOшников, а сейчас поведаю о том, как мы ведем учет рабочего времени и зачем вообще это делаем.
В штате компании – 90 человек. Управлять таким количеством сотрудников и контролировать их не у всех получается хорошо. Из-за неэффективного управления может проседать качество услуг компании, снижаться рентабельность проектов, ухудшаться общий климат в офисе. Чтобы этого избежать, мы внедрили у себя мониторинг эффективности работы сотрудника.
Читать полностью »
Мы приглашаем вас 3 июля на большой Open Demo Day в Райффайзенбанк, который состоится в Нагатино. Наши команды будут показывать живые демо, а вы первыми увидите то, что вот-вот появится на проде.
В Райффайзенбанке мы проводим демо-дни каждый месяц, и хотим не только показать продуктовую часть этого события, но также рассказать и продемонстрировать вам, как это помогает нам делать банк лучше.
Сейчас для многих тема очень актуальна цифровых трансформаций. На каждой около-ИТ конференции все рассказывают о своем опыте и делятся сложностями, которые были на пути. Истории с цифровизациями, трансформациями, аджайлизациями действительно интересны, и компании сталкиваются с большими сложностями, как техническими, так и социальными, и культурными.
Четыре года назад база клиентов велась отдельно в каждом магазине плюс ещё одна — на сайте.
В предыдущих сериях: три года назад мы решили, что нужно делать свою разработку в России. Два года назад начали писать собственный код вместо того, чтобы модифицировать форк кода материнской компании. Сегодняшняя история будет про то, как мы переключались с одного большого легаси-монолита на кучу маленьких микросервисов, соединённых своего рода шиной (оркестратор).
Самый простой юзеркейс: сделать заказ через сайт и забрать его в реальном магазине «Леруа Мерлен» в России. Раньше заказы интернет-магазина обрабатывались в другом приложении вообще и по другой схеме. Теперь нам нужна была омниканальная витрина, чтобы любой заказ был разбит на интерфейс: касса в магазине, мобильное приложение, терминал в магазине, сайт — что угодно. Если вы поставите Linux на микроволновку — пускай будет микроволновка. Главное, чтобы какие-то интерфейсы могли стучать по API к беку и говорить, что вот тут надо оформить такой-то заказ. И получали на это внятный ответ. Вторая история была с запросами наличия и свойств товара из его карточки.
На фронте (скоро и про это напишем) у нас монстр — AEM, а за ним в беке было два больших приложения: OPUS и MoVe. Первое — это база данных свойств каждого товара (от габаритов до описания), второе — отвечает за чекаут, то есть монолит касс. Если сильно упростить.Читать полностью »
