dimitrypikabu

dimitrypikabu

Телеграм-канал: https://t.me/samvsepoimesh Мы собираем самые актуальные материалы, анализируем тренды и делимся проверенными методиками для успешного ведения IT-проектов. Наш канал предназначен как для опытных профессионалов в области управления проектами в IT-сфере, так и для тех, кто только начинает свой путь в этой области и жаждет знаний.
Пикабушник
Дата рождения: 15 ноября
поставил 200 плюсов и 32 минуса
в топе авторов на 534 месте
112 рейтинг 5 подписчиков 10 подписок 14 постов 0 в горячем

Что мешает стартапам взлететь

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

Что мешает стартапам взлететь Управление проектами, Стартап, Заблуждение, Мифы, Длиннопост

Миф №1: Главное — идея На самом деле. Идея — лишь необходимое условие, но никак не гарантия успеха. Гораздо важнее реализация, от деталей которой зависит всё. Куда разумнее взять давно известную идею и отжать долю рынка у конкурентов, чем гнаться за чем-то уникальным.

Миф №2: Нужно найти незанятую нишу. Незанятых ниш просто не существует. Даже если сейчас рынок свободен, как только ваш стартап станет успешным, конкуренты не заставят себя ждать. Лучше сразу готовиться к борьбе, оценивая свои конкурентные преимущества.

Миф №3: Нужно делать все идеально с самого начала. Погоня за совершенством — верный путь к провалу. Необходимо создать MVP - минимально работоспособный продукт - и далее эволюционировать, опираясь на реальные данные. Сначала нужно просто запуститься, пусть и с "говнокодом". Идеальный продукт вы все равно переделаете множество раз.

Миф №4: Я могу вести несколько проектов одновременно. Разделив внимание, вы проиграете тем, кто сосредоточен на одном направлении. Время играет критическую роль, поэтому предпринимателям приходится столько работать.

Миф №5: Мои расчеты верны. Смотри миф №3. Реальность быстро опровергнет любые изначальные расчеты.

Миф №6: Есть пассивный доход от стартапа. В редких случаях это возможно, но чаще всего проект, подобно велосипеду — либо движется вперед, либо падает. Вы должны постоянно его развивать, конкуренты не дадут расслабиться.

Миф №7: Я знаю рынок, потому что я пользователь. Нередко разработчики думают, что создают продукт под себя, но на деле он никому больше не нужен. Критически важно проверять свои предположения опросами и общением с аудиторией.

Миф №8: Нужно копировать успешные западные продукты/конкурентов. Российский рынок сильно отличается от западного менталитетом, культурой и платежеспособностью. То, что работает там, здесь может провалиться. Копирование конкурентов также бесперспективно — догоняющие всегда будут в проигрыше.

Миф №9: Трафик важнее всего Гораздо важнее правильный трафик и эффективная конверсия посетителей в покупателей. Вы должны четко понимать свою целевую аудиторию.

Миф №10: Мне подойдет рецепт успеха кого-то другого У каждого свой путь, попытки слепо следовать чужим историям обречены. Лучший совет - находить и использовать свои сильные стороны, а не пытаться кому-то подражать.

Миф №11: Факапа не будет. Ошибки неизбежны. Важна скорость их осознания и способность делать правильные выводы, опережая конкурентов.

В заключение хочу процитировать мудрые слова Стива Джобса: "Stay hungry. Stay foolish". Сохраняйте страсть к развитию, но также помните о собственном невежестве. Эти два качества защитят вас от опасных заблуждений и не дадут свернуть с верного пути.

Хотите углубить свои знания об управлении проектами (стартапами) и избежать распространенных ошибок? Тогда обязательно подпишитесь на канал Самоучки IT (Управление проектами) https://t.me/samvsepoimesh .

Показать полностью 1

Жесткие методы для хрупких сотрудников: безопасный путь к дисциплине

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

Жесткие методы для хрупких сотрудников: безопасный путь к          дисциплине Развитие, Карьера, Управление проектами, Саморазвитие, Дисциплина, Наказание, Длиннопост

Если вам интересна тематика развития управленческих навыков в сфере IT, то на канале "Самоучки (ITУправление проектами)" https://t.me/+NfVrLMxdKS0yNDNi , где много полезных материалов на эту и другие темы.

Отсутствие обучения

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

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

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

Высокая точность

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

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

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

Два принципа регулярного менеджмента

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

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

В регулярном менеджменте этот вопрос решается с помощью двух основополагающих принципов:

1.Руководитель обязан применить дисциплинарное взыскание, если подчинённый нарушил доведённые до него правила и инструкции.

Например, менеджер поручил джуниор-программисту Петру спроектировать базу данных и привлечь к работе опытную Катю в качестве помощницы. Петр попросил Катю, но она отказалась. Тогда Петр в одиночку изучил дополнительные материалы и все же справился с заданием. Казалось бы, молодец! Но в системе регулярного менеджмента Петра все равно нужно наказать за самовольные действия вопреки инструкции. Хотя с точки зрения импровизационного подхода его можно было бы даже наградить.

2.Руководитель не имеет права наказывать подчинённого, действовавшего строго в рамках своих полномочий.

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

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

Амнистия и самоанализ

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

Амнистия возможна только в том случае, если человек способен к искреннему самоанализу и осознанию причин своего проступка. В японской культуре это называется "хансей". У нас такая саморефлексия встречается редко, но ее можно стимулировать, проводя глубокий "root cause analysis" ситуации совместно с провинившимся сотрудником. Подробно проанализировав свои действия и поведение, человек сможет предложить меры по недопущению подобных инцидентов в будущем.

Дистанцирование

Наказание может заключаться в изменении комфортной для сотрудника дистанции в его взаимодействии с руководителем. Менеджер вправе либо приблизить, либо отдалить подчинённого посредством неудобных вопросов, вынуждающих заглянуть в себя. Самое строгое наказание - увольнение, максимальное отдаление.

Менеджер должен заранее продумать арсенал наказаний разной степени жёсткости. Конечно, применять их на практике необязательно. Но осознание того, что у вас есть разные методы воздействия, сделает вас более уверенным руководителем.

Задавайте правильные вопросы наедине

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

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

Типичные отговорки

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

Остудите гнев руководителя

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

Соблюдайте баланс

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

Не все поддаются наказаниям

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

Тренируйтесь на "расходном материале"

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

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

Контрольный список

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

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

  • Старайтесь достичь максимальной точности в формулировках, предъявляемых сотруднику претензий

  • Уясните разницу между моральным и материальным наказанием, вторые в интеллектуальной сфере неэффективны

  • Изучите принципы регулярного менеджмента, чтобы правильно реагировать на разные ситуации

  • Не путайте наказание с обидой, ваша цель - не унизить человека, а донести до него осознание вины

  • Разработайте процедуру реальной амнистии после раскаяния, не оставляйте зависших конфликтов

  • Обратите внимание на метод root cause analysis, он поможет сотруднику сделать выводы

  • Старайтесь не выплёскивать эмоции, действуйте через точные вопросы и изменение дистанции

  • Заранее распишите себе арсенал дисциплинарных мер разной степени жёсткости

  • Учитесь игнорировать характерные отговорки и отмазки

  • Не допускайте переноса стресса и долговременного гнева от провинившихся сотрудников

  • Соблюдайте баланс между наказаниями и поощрениями

  • Не тратьте усилия на самокритичных сотрудников, которые сами себя накажут

  • При невозможности практиковаться на "жертвах" используйте любой доступный "расходный материал"

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

Ищите также другие материалы для развития навыков менеджера в IT-сфере на канале "Самоучки (ITУправление проектами)" https://t.me/+NfVrLMxdKS0yNDNi

Успехов!

Показать полностью 1

Git Flow. Разделяй и властвуй: Сила ветвления в разработке ПО

Продолжая тему управления проектами в IT-сфере, хочу затронуть один важный аспект - ветвление (branching) в системах контроля версий, таких как Git.

Git Flow. Разделяй и властвуй: Сила ветвления в разработке ПО Управление проектами, Agile, Git, Длиннопост

В Телеграм есть канал "Самоучки IT(Управление проектами)" https://t.me/+NfVrLMxdKS0yNDNi где регулярно пополняется  материал по  всем этим вопросам.

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

Git Flow - это методика, которая позволяет использовать функциональные ветки для внедрения фич и набор основных веток, которые позволяют делать релизы. Эта методика хорошо подходит для проектов, жизненный цикл которых составляет один или две недели. Я лично использую Git Flow в 95% своих проектов, которые я веду вместе с командами, и могу с уверенностью сказать, что она очень хорошо подходит для Agale методологий, таких как, Scrum где спринты длительностью одна или две недели.

Давайте теперь разберемся, что стоит за Git Flow и как по нему работать. Начнем с того, что Git Flow - это методика, которая предоставляет функциональные ветки для внедрения фич и набор основных веток, которые позволяют делать релизы или трясти наш успех. Все начинается с двух основных веток: Main (или Master) и Develop.

На вершине ветки Main создаются теги, которые служат для маркировки определенных моментов в истории разработки проекта. Эти теги используются для сборки проекта, выпуска САСД и других процессов, связанных с релизами. Таким образом, ветка Main остается стабильной и содержит только версии проекта, готовые к развертыванию в продакшен..

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

Далее, когда мы хотим внедрить какую-то фичу, мы создаем отдельную ветку от Develop, которую называем Фичер веткой. Фичер ветка - это ветка, которую берут от Develop, когда приходит и хочет внедрить какую-то фичу, разработчик. В этой ветке работы он может ковать сколько угодно комитов, всё что угодно делать и в результате, получать какой-то финальную работающую фичу или исправленный баг, если мы говорим о баг.

Когда фича готова, ее нужно влить в Develop. Для этого мы создаем Pull Request (PR)и просим кого-нибудь из команды проверить наш код. Этот процесс называется Код Ревью. Код Ревью - это очень важный процесс, который позволяет нам доставлять качественный код в продакшен. Поэтому без Код Ревью мы не можем влить нашу фичу в Develop.

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

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

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

Итак, мы рассмотрели основные ветки и процессы, которые используются в Git Flow. Давайте теперь рассмотрим некоторые практические примеры использования Git Flow.


Пример 1. Внедрение новой фичи.

Предположим, нам нужно внедрить новую фичу в нашем проекте.

Для этого мы выполняем следующие шаги:

Создаем новую ветку от Develop, например: git checkout -b feature/my-new-feature develop

Делаем необходимые изменения в коде и комитим их: git add .; git commit -m "Add my new feature"

Отправляем наши изменения на удаленный репозиторий: git push origin feature/my-new-feature

Создаем Pull Request в Develop.

- Просим кого-нибудь из команды проверить наш код и дать комментарии.

-Вносим необходимые изменения на основе комментариев и отправляем их в Pull Request.

Когда наш код прошел Код Ревью, мы вливаем его в Develop: git checkout develop; git pull; git merge feature/my-new-feature; git push origin develop

Удаляем нашу Feature ветку: git branch -d feature/my-new-feature


Пример 2. Исправление критической ошибки в продакшене.

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

- Создаем новую ветку от Main, например: git checkout -b hotfix/critical-bug-fix master

-Делаем необходимые изменения в коде и комитим их: git add .; git commit -m "Fix critical bug"

-Отправляем наши изменения на удаленный репозиторий: git push origin hotfix/critical-bug-fix

-Создаем Pull Request  в Main.

-Просим кого-нибудь из команды проверить наш код и дать комментарии.

-Вносим необходимые изменения на основе комментариев и отправляем их в Pull Request.

-Когда наш код прошел Код Ревью, мы вливаем его в Main : git checkout master; git pull; git merge hotfix/critical-bug-fix; git push origin master

-Создаем новый тег с номером релиза: git tag -a v1.1.1 -m "Hotfix release"

-Вливаем наш hotfix  в Develop : git checkout develop; git pull; git merge hotfix/critical-bug-fix; git push origin develop

-Удаляем нашу hotfix  ветку: git branch -d hotfix/critical-bug-fix

Итак, мы рассмотрели основные ветки и процессы, которые используются в Git Flow, а также практические примеры их использования. Git Flow - это очень мощная и гибкая методика, которая позволяет нам эффективно работать с гитом и контролировать процесс разработки. Если вы еще не используете Git Flow в своих проектах, я рекомендую вам его попробовать. Вы не пожалеете!

Ну и в конце небольшое примечание. Git Flow - это не догма, а всего лишь набор рекомендаций, которые можно изменять под свои нужды. Если какой-то процесс не подходит вашей команде, вы всегда можете его изменить или вообще не использовать. Главное - чтобы процесс работы был понятен всем участникам команды и не мешал эффективной разработке. Пользуйтесь на здоровье, а подробности изучайте в канале "Самоучки IT(Управление проектами) " https://t.me/+NfVrLMxdKS0yNDNi  - там  много годного материала и обсуждения!

Показать полностью 1

Формула SMART: как ставить цели, которые реально работают

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

Формула SMART: как ставить цели, которые реально работают Карьера, Проект, Обучение, Развитие, Личный опыт, Управление проектами, Smart, Длиннопост

Я знаю, что многие из вас, кто смотрит мой канал Самоучки IT(Управление проектами) https://t.me/+NfVrLMxdKS0yNDNi, работают в IT-сфере или связаны с ней. Программисты, менеджеры проектов, дизайнеры, аналитики и другие специалисты. И, конечно же, у каждого из вас есть определенные цели — как профессиональные, так и личные.

Например, кто-то хочет стать лидом разработки за год-два. Кто-то мечтает открыть свой стартап. А кто-то просто хочет найти интересную и высокооплачиваемую работу в крупной IT-компании. Но очень часто мы формулируем свои цели слишком расплывчато, как "стать успешным" или "достичь карьерных высот". Это не цели, а скорее мечты или желания.

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

SMART - это аббревиатура, в которой каждая буква означает один из критериев эффективной цели:

S - Specific (конкретная)

M - Measurable (измеримая)

A - Achievable (достижимая)

R - Relevant (актуальная)

T - Time-bound (ограниченная по времени)

Давайте разберем каждый из этих критериев на примере нашей сферы деятельности - IT.

Specific (конкретная)

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

Вместо этого сформулируйте цель более конкретно. Например, "Достичь уровня Middle Python Developer и перейти на позицию лида в команде разработки мобильных приложений в компании X за 2 года". Или "Выучить JavaScript и React и найти работу фронтенд-разработчика в продуктовой IT-компании через год".

Чем конкретнее цель, тем легче будет определить шаги для ее достижения и отслеживать прогресс.

Measurable (измеримая)

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

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

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

Achievable (достижимая)

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

Спросите себя честно: "Могу ли я реально этого добиться?". Если цель кажется слишком сложной или нереалистичной, разбейте ее на несколько этапов. Например, вместо "Стать ведущим экспертом по искусственному интеллекту за год" поставьте цель "Выучить основы машинного обучения и нейросетей и создать первый успешный проект в этой области за год".

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

Relevant (актуальная)

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

Спросите себя: "Зачем мне это нужно? Как это соотносится с моими истинными ценностями, интересами и жизненными планами?". Например, если ваша страсть - frontend-разработка, то нет смысла ставить цель стать лучшим бэкенд-разработчиком, только потому что это престижно или высокооплачиваемо.

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

Time-bound (ограниченная по времени)

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

Поставьте себе четкий и реалистичный срок, к которому вы должны достичь цели — будь то месяц, год или несколько лет. Разбейте этот период на этапы с промежуточными контрольными точками, чтобы отслеживать прогресс. Например: "Выучить Python и Django и разработать полноценное веб-приложение за 9 месяцев". При этом разбейте эту цель на этапы:

1-3 месяцы — изучить основы Python и его синтаксис

4-6 месяцев — освоить Django и разработку на нем

7-9 месяцы — создать и запустить веб-приложение

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

Теперь давайте рассмотрим пару конкретных примеров умных целей в IT согласно методологии SMART.


Пример 1: Стать Senior Java Developer

Цель: Достичь уровня Senior Java Developer и перейти на соответствующую позицию в компании X к концу 2025 года.

S (Specific): Четко определена цель — стать Senior Java разработчиком в конкретной компании X.

M (Measurable): Можно измерить успех назначением на должность Senior и переходом к ответственности на этом уровне.

A (Achievable): Достижимо при условии наличия 5+ лет опыта в Java разработке, знании фреймворков, владении английским и готовности постоянно учиться.

R (Relevant): Актуально для того, кто страстно увлечен Java и хочет развиваться как технический эксперт в этой области.

T (Time-bound): Крайний срок — конец 2025 года, т.е. около 2,5 лет на подготовку.


Пример 2: Запустить собственный стартап

Цель: Создать успешный IT-стартап в сфере финтеха и привлечь инвестиции в размере $500 000 к концу 2026 года.

S (Specific): Четкая цель по созданию стартапа в конкретной отрасли и привлечению определенной суммы инвестиций.

M (Measurable): Успех можно измерить самим фактом запуска работающего стартапа и объемом привлеченных инвестиций.

A (Achievable): Достижимо при наличии сильной идеи, команды единомышленников, плана действий и определенного базового капитала.

R (Relevant): Актуально для тех, кто хочет реализовать свои амбиции в сфере инноваций и предпринимательства в IT.

T (Time-bound): Крайний срок — конец 2026 года, т.е. около 3 лет на разработку идеи, создание MVP и поиск инвесторов.

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

Итак, давайте подведем итог тому, что мы узнали:

Четкая цель — ключ к мотивации и успеху в любой сфере, в том числе IT.Методология SMART позволяет сформулировать цель правильно по 5 важнейшим критериям:

S (Specific) - конкретная

M (Measurable) - измеримая

A (Achievable) - достижимая

R (Relevant) - актуальная для вас

T (Time-bound) - ограниченная по времени

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

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

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

Разбивайте большие цели на промежуточные этапы. Так будет проще отслеживать прогресс.

Регулярно анализируйте свои достижения и ошибки на пути к цели. Учитесь на них.

Не забывайте ставить перед собой SMART-цели и придерживаться методологии их грамотной постановки.

В завершение еще раз напомню про отличный телеграм-канал Самоучки IT(Управление проектами) https://t.me/+NfVrLMxdKS0yNDNi, посвященный самообучению и построению карьеры в IT, особенно в управлении проектами. Его создатели регулярно публикуют вдохновляющие истории самореализации, разборы полезных книг, советы по подготовке к собеседованиям и многое другое. И кто еще не подписан, подписывайтесь на канал. Делайте репост этой статьи в соцсетях.

Я уверен, что эту методику полезно знать каждому.

Всего доброго!

Показать полностью 1

Исповедь опытного PM: ошибки, которые лучше не повторять

Быть Project -менеджером – это непростая задача, требующая постоянного самосовершенствования. За годы работы в этой сфере, набил немало шишек и совершил массу ошибок. Пришло время поделиться некоторыми из них, дабы предостеречь вас от подобных промахов.

Исповедь опытного PM: ошибки, которые лучше не повторять Управление проектами, Личный опыт, Длиннопост, Менеджер, Совет

Как отмечают на канале "Самоучки IT (Управление проектами)" https://t.me/+NfVrLMxdKS0yNDNi , ключевая роль Project -менеджера - создать оптимальные условия для продуктивной работы команды. Это предполагает четкое определение зон ответственности, устранение препятствий и расстановку приоритетов, на которых следует сфокусироваться. Однако даже опытные управленцы нередко наступают на многочисленные "грабли", допуская распространенные ошибки. Об этом из личного опыта расскажет опытный PM.

Ошибка №1. Думать за пользователей и заказчика

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

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

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

 Пришло время расстаться с этой порочной практикой. Не думайте за пользователей и заказчиков – общайтесь с ними, уточняйте требования, собирайте обратную связь, применяйте соответствующие техники. Это не трата времени, а инвестиция в успешность проекта.

 

Ошибка №2. Думать за команду

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

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

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

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

 

Ошибка №3. Микроменеджмент

Микроменеджмент – ахиллесова пята многих руководителей проектов, включая меня. Эта зловредная практика выражается в том, что менеджер начинает пристально отслеживать каждый шаг членов команды: сколько времени кто провел в Zoom, какие задачи передвинул из одного статуса в другой и т.д. Дело доходит до абсурдных ситуаций, когда люди вынуждены выжидать, пока я одобрю их малейшее действие.

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

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

 

Ошибка №4. Замалчивать проблемы

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

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

 Поэтому не замалчивайте проблемы. Если ситуация еще не зашла слишком далеко, на ранней стадии вы имеете дело с управляемым риском, а не свершившимся фактом. Открыто говорите о них, не стесняйтесь просить совета и помощи. И что еще более важно – создавайте в команде атмосферу доверия, чтобы и ее члены могли откровенно делиться своими трудностями. Только так удастся предупредить многие беды и свести их негативный эффект к минимуму.

 

Ошибка №5. Делать работу за других

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

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

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

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

 

Ошибка №6. Зарываться в бумажной работе

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

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

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

 

Ошибка №7. Тушение пожаров вместо планирования

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

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

 Истина, как часто бывает, находится посередине. Конечно, нужно быть готовым к изменениям. Но это никак не отменяет саму необходимость планирования и ревизии планов. Ведь взгляните на ситуацию с другой стороны: когда вы садитесь за руль в большом городе, пусть и знакомом, разве не проще выстроить маршрут заранее? Он будет обновляться в режиме реального времени и поможет объехать пробки, найти оптимальный путь и сэкономить массу времени. Достаточно потратить на это 30 секунд!

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

 

Ошибка №8. Игнорирование рисков

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

 "В нашем проекте нет никаких рисков!"

"Я ничего не могу придумать!"

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

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

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

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

Ошибка №9. Многозадачность

Многозадачность я ненавижу даже сильнее, чем микроменеджмент. Это зло, которое многие почему-то считают добродетелью и проявлением выдающихся способностей. Но результаты исследований неумолимы – лишь 2% людей действительно способны эффективно совмещать множество дел одновременно. Остальные 98%, переключаясь между задачами, стремительно теряют продуктивность.

 Я, к сожалению, отношусь к этим 98%. В прошлом я постоянно брал на себя больше, чем мог осилить. Создавал целые горы незавершенной работы, становился бутылочным горлышком проектов. Мысли моим постоянно витали где-то, я никак не мог сфокусироваться на одном деле как следует.

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

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

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

Спасибо, что вы дочитали до конца.

Подписывайтесь на наш канал Самоучки IT (Управление проектами) https://t.me/+NfVrLMxdKS0yNDNi

Показать полностью

Как понимать язык DevOps: введение в Docker и контейнеризацию

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

Сегодня мы раскроем завесу этой тайны и научим вас понимать язык DevOps.

Как понимать язык DevOps: введение в Docker и контейнеризацию DevOps, Docker, Виртуализация, Длиннопост

Друзья, перед тем как углубиться в тему Docker и контейнеризации, рекомендуем подписаться на канал Telegram "Самоучки IT (Управление проектами)" https://t.me/+NfVrLMxdKS0yNDNi . Этот канал охватывает широкий спектр тем, связанных с управлением IT-проектами, DevOps и многим другим.

Представьте, что ваш коллега-разработчик написал программу на одном из языков программирования, запустил ее в своем дистрибутиве Linux, добавил множество дополнительных программ, необходимых для запуска, и теперь вам нужно все это запускать, интегрировать с другими частями вашего общего приложения и предоставлять клиентам. Как скопировать все необходимое для работы программы, чтобы ее можно было запускать везде и она работала одинаково?

Одним из решений могут быть виртуальные машины (ВМ). Если вы не знакомы с этим термином, то вкратце это как будто бы вы создали еще один компьютер внутри вашего компьютера. В этой схеме у нас есть наш сервер, на нем установлена операционная система (ОС), а поверх нее работает гипервизор, например, Hyper-V, VMware ESX или VirtualBox, который эмулирует железо и управляет виртуальными машинами. Каждый экземпляр ВМ имеет собственную ОС, которая называется гостевой, и приложения работают уже внутри нее. Таким образом, вы можете на одном сервере запускать множество разных ОС и приложений.

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

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

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

При этом приложения остаются все так же изолированы от системы и других приложений. Кстати, Docker не единственная технология контейнеризации, но определенно самая популярная.

Давайте теперь поговорим о самом Docker. Здесь нужно знать о трех основных элементах: Dockerfile, образ и контейнер. Взаимодействие между ними такое: из Dockerfile собирается образ, а на основе образа запускается контейнер.

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

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

Давайте рассмотрим это на примере. Создадим Dockerfile и напишем в нем следующее:

Как понимать язык DevOps: введение в Docker и контейнеризацию DevOps, Docker, Виртуализация, Длиннопост

Это значит, что мы берем за основу существующий образ Ubuntu версии 20.04, устанавливаем веб-сервер nginx, открываем порт 80 и запускаем сервер при старте контейнера.

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

После создания образа можно запустить из него контейнер, выполнив команду docker run. Теперь, если мы откроем браузер и наберем в адресной строке localhost, то увидим, что все работает.

Вот так просто, используя различные команды, мы можем создавать и запускать свои контейнеры. Однако, если нам не требуется сложная настройка образа, а нужно просто получить работающую программу, то мы можем скачать готовый образ из Docker Hub и запустить его, выполнив команду docker pull и docker run.

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

Подводя итоги, можно сказать, что Docker - это не только модное слово, которое поможет повысить вашу зарплату, но и мощный инструмент, который объединяет в себе все, что нам нравится в IT: автоматизацию, скорость, консистентность, модульность, экономичность и классный логотип.

И если вы еще не знакомы с Docker, то пора исправить это. Ну и под конец вопрос к знатокам. Если докер такой классный, то почему он до сих пор не выдавил с рынка  виртуальные машины? В каких задачах без виртуалок не обойтись?

Для получения дополнительных знаний и инсайтов в области управления IT-проектами, DevOps и смежных тем, рекомендуем подписаться на канал Telegram "Самоучки IT (Управление проектами) https://t.me/+NfVrLMxdKS0yNDNi

Показать полностью 2

CI/CD: от теории к практике - реальный пример успешного внедрения

В этой статье я расскажу вам о концепции CI/CD, которая является неотъемлемой частью современной разработки программного обеспечения.

Сегодня порассуждаем про концепцию CI/CD, которая ныне на пике популярности в разработке софта.

CI/CD: от теории к практике - реальный пример успешного внедрения Agile, DevOps, Автоматизация, Тестирование, Управление проектами, IT, Карьера, Длиннопост

Также найти  множество интересной и полезной информации вы можете на канале Самоучки IT (Управление проектами) https://t.me/+NfVrLMxdKS0yNDNi

CI/CD - это Continuous Integration, Continuous Delivery - непрерывная интеграция, непрерывная поставка. Это одна из DevOps-практик, которая также относится к Agile-подходу. Автоматизация развёртывания позволяет разработчикам сфокусироваться на реализации бизнес-требований, качестве кода и безопасности.

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

Многие ошибочно думают, что CI и CD - разные процессы. Но на самом деле они связаны как матрёшки. Внутри - непрерывная интеграция, снаружи - непрерывная доставка. Основная их цель - увеличить стабильность выпусков и ускорить весь этот процесс.

Давайте по-полочкам разберём этапы CI/CD цикла:

  • Код . На этом этапе идёт написание кода, покрытие его тестами, commit и push в систему контроля версий

  • Сборка. Система вроде Jenkins автоматически собирает ваши изменения и запускает их тестирование.

  • Тестирование. После успешного прохождения автоматических тестов изменения отдаются на ручное тестирование.

  • Релиз. После того, как команда тестировщиков проверила все изменения, у нас получается стабильная версия продукта – релиз-кандидат.

  • Деплой. Релизную ветку мы загружаем и разворачиваем на продакшен-сервере клиента.

  • Мониторинг. Следим за развёрнутой версией продукта и в случае проблем стабилизируем её или фиксим.

  • Планирование. Планирование новой функциональности или внесение изменений для будущих релизов.

Теперь разберем, как CI/CD помогает автоматизировать эти шаги.

Непрерывная интеграция — это автосборка и тестирование всего кода в общем репозитории после слияний. Команды часто используют feature flags или ветки для контроля готовности функционала. CI позволяет выявлять проблемы до деплоя кривого кода на прод.

На этапе сборки упаковываются все компоненты ПО и БД. Запускаются модульные, функциональные, регрессионные тесты и другие виды тестов для проверки стабильности. Это непрерывное тестирование - важная часть CI/CD.

Следующий этап - непрерывная поставка. Тут автоматизируется процесс подготовки релиза к деплою после CI. Настраиваются параметры окружений, выполняются необходимые запросы для перезапуска сервисов и т.д. DevOps команда берет протестированный релиз и выполняет все действия для деплоя на проде в пару кликов.

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

Ещё один важный момент - CI/CD конвейеры широко используются с Kubernetes и бессерверными архитектурами. Контейнеры позволяют стандартизировать упаковку, упрощают масштабирование окружений. А бессерверные вычисления типа AWS Lambda интегрируются в конвейеры через плагины.

В компаниях, где CI/CD внедрён, часто улучшаются ключевые DevOps метрики: частота деплоев, lead time для изменений, время восстановления после инцидентов. Но для этого нужно наладить весь процесс по методологии DevOps.

В общем, CI/CD - мощная практика для автоматизации разработки и деплоев. Команда разработчиков просто пишет код, а остальные шаги в конвейере выполняются на автомате. Такой подход экономит время и обеспечивает стабильность ПО.

А чтобы все это не было просто сухой теорией, расскажу реальный кейс из жизни.

Однажды мне довелось поработать в одной прогрессивной конторе, где CI/CD был поставлен на самом деле очень грамотно.

Команда разработчиков активно писала код в feature branches регулярно создавая pull request, для слияния изменений в мастер-ветку. После каждого такого merge автоматически запускался конвейер CI. Система типа Jenkins забирала новый код, собирала приложение, гоняла batch -тестов - юнит, интеграционные, регрессионные. Все это не занимало больше 10 минут.

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

Но самое крутое начиналось дальше. После успешной поставки в тест-окружения запускалась финальная стадия - непрерывное развёртывание. Конвейер автоматически деплоил собранную версию на продакшен сервера, обновлял контейнеры, переключал трафик, и свежая фича становилась доступной всем пользователям!

Согласитесь, это было очень круто - от написания строчки кода до релиза проходило всего минут 30 максимум, если все шло штатно. При этом человеческое вмешательство требовалось только на самом старте - commit изменений. Остальным занималась магия CI/CD.

Плюс в углу офисной площадки красовался большой ТВ-экран, где транслировался статус всех активных сборок и деплоев - кто закоммитил (committed), на какой стадии идёт процесс, есть ли ошибки. Так что любой мог присмотреться если что пошло не так.

В общем, навороченный CI/CD конвейер сильно упрощал жизнь разработчикам и DevOpsам, позволяя много времени сэкономить на рутинных задачах поставки кода на прод. Да и со стабильностью системы не было никаких проблем благодаря повсеместному тестированию. Так что если доведёте CI/CD до ума, то только в плюсе будете!

Ну что? Я надеюсь, теперь у вас более-менее все встало на свои места с этой концепцией. Оставляйте свои мнения и кейсы в комментах.  Будем продолжать разбираться в крутых IT-темах на канале Самоучки IT(Управление проектами)https://t.me/+NfVrLMxdKS0yNDNi

Показать полностью

"Да" Scrum и "Нет" неудачам"

Прежде чем мы углубимся в статью, я хотел бы упомянуть канал "Самоучки IT (Управление проектами) https://t.me/+NfVrLMxdKS0yNDNi, где вы найдете много полезных материалов для изучения Scrum и других IT-методологий.

"Да" Scrum и "Нет" неудачам" Разработка, Agile, Длиннопост

Введение в мир Scrum

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

Основы Scrum: роли, артефакты и церемонии

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

Артефакты Scrum – это своего рода «трофеи» процесса разработки. Бэклог продукта – это своеобразный список желаний, где собраны все требования к продукту. Бэклог спринта – это выборка из общего списка, задачи для одного спринта. График сгорания – это инструмент для отслеживания прогресса, показывающий, сколько работы сделано и сколько еще осталось.

Церемонии Scrum – это своеобразные «фестивали» методологии, где команда собирается, чтобы планировать, обсуждать прогресс и показывать результаты. Планирование спринта, ежедневные Scrum-собрания и обзор спринта – каждое из них играет свою роль в поддержании эффективности и прозрачности процесса.

Scrum в деле: Пример применения в разработке калькулятора цен

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

Роль Владельца Продукта (Product Owner):

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

Роль Разработчика (Developer):

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

Сессия Планирования Спринта (Sprint Planning):

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

Спринт (Sprint):

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

Обзор Спринта (Sprint Review):

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

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

Подробности в деталях: детализация задач и коммуникация

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

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

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

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

Гибкость и успех

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

Заключение:

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

Канал Самоучки IT(Управление проектами)  https://t.me/+NfVrLMxdKS0yNDNi, где мы регулярно публикуем образовательный контент.

Показать полностью 1
Отличная работа, все прочитано!