Проекты

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

Начало

Перчатка вытекла прямиком из моего проекта Mark, кроме того она является его значимой частью, так что начать следует с него.

Самый первый прототип робота был сделан в один из вечеров лета 2018 года. Это был четвероногий робот, состоящий из 8 сервоприводов SG90(обычных синих) и кусков гвоздей. Соединялось всё это термоклеем и не имело ни единого шанса на нормальную работу ввиду очень неудачного распределения массы. Но я этого не знал и в тот же вечер заставил его шагать по прямой, а ещё через минут 15 после этого плата, через которую шло питание, задымилась и на столе оказался отпаявшийся линейный стабилизатор (к слову я так и не понял что там произошло).

Починить эту горку термоклея гвоздей и изоленты я так и не смог. В своё оправдание могу сказать, что в тот момент я не умел паять, из электроники понимал только что нельзя замыкать + и -, а о существовании 3D печати и не слышал.

В конце лета заказал себе первый принтер - Anet A8.

Обычный принтер для ознакомления с технологией: рама из акрила, кинематика с "дрыгостолом" и шумные моторы (скорее их драйвера)

Почти сразу после его покупки я освоил tinkercad, где и воссоздал того робота на 4 ногах уже с заменой гвоздей на пластик и добавлением поворотного сервопривода.

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

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

С последней и предпоследней версией я победил на 2 мероприятиях и решил расширять серию Mark. Именно так на скорую руку я записал относительно нереальные планы на роботов, включая большие металлические базы для роботов. Но затем я всё же переосмыслил идею серии - можно же сделать реально интересную систему марсоходов, которая может себя показать и на Земле.

Собственно вот как я пока что это позиционирую:

Система роботовMark- это исследовательский комплекс дляавтономногоисследования местности, в частности - поверхностиМарса.

Mark6 - основная база, предназначен для защиты остальныхроботовот неблагоприятных условий.

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

Mark4 -шнекоход, также выполняет роль спасательного аппарата.

Mark5 -инсектоидс крыльями и 6 ногами. Может использоваться дляизученияочень узких проходов.

Mark7 -робозмея, также как иMark5 может исследовать узкиепроходы иотверстия.

Markgauntlet перчатка для ручного управления всеми роботами.

Из представленных роботов у меня есть почти готовые Mark 6, Mark 4, ну и собственно Mark 3 и Mark gauntlet.

Из интересного по ним пока есть только основа Mark 6 и его шасси, которые пока печатаются

Разработка перчатки: версия 1

Первая версия перчатки была сделана весной 2020 года и сразу заработала с тестовым стендом, но там мало что могло не сработать: я использовал обычный радиомодуль на 433 МГц с антенной из куска провода. Более подробно там есть в видео (моё первое видео, так что там всё очень посредственно) https://youtu.be/eEAHhr9Suug?t=194

Разработка перчатки: версия 2

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

Тут уже был радиомодуль nrf24l01, несколько режимов работы и выбор канала передачи. На работу перчатки можно глянуть в видео https://youtu.be/P_fq7KkfJrI

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

Разработка перчатки: версии 3 и 4

Обе имеют схожий функционал и были сделаны каждая за пару дней.

3 версия:

Функционал:

• WiFi модуль esp8266

• Радиомодуль NRF24l01+

• Мини радиомодуль на 433 МГц

• Bluetooth модуль

• Акселерометр + гироскоп на перчатке

• Панель управления с OLED дисплеем

В целом получилась нормальная версия, но её было бы сложно повторять из-за пайки навесом прямо на корпусе. Вот подобие описания этой версии https://youtu.be/52WvejA6dyk .

4 версия:

Тут уже я взял всё что подходило под концепцию и добавил к этому контроллер Atmega2560

Видео с процессом её создания:

Функционал:

• WiFi модуль

• Радиомодуль NRF24L01+

• Радиомодуль LoRa

• MP3 плеер и динамик к нему

• ИК- светодиод (для простейшей связи)

• Мощные адресные светодиоды сбоку

• Акселерометр+гироскоп

• Датчик цвета + жестов

• Панель управления с OLED дисплеем

На этом можно было бы и остановиться, но я решил пойти дальше и сделать версию 4.2

Версия 4.2 или завершающий штрих перчатки

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

Основа возвращается с первой версии из-за подходящей геометрии

Перчатка скорее всего останется с версии 4

Для питания будут использоваться 3 аккумулятора 18650 на 3.4 А*ч каждый, что обеспечит достаточно большую автономность. Крепиться это будет на плечо.

Почти вся электроника будет распаяна на 2 печатные платы, которые соединятся вместе

Ну и первоначальный код, который будет использоваться для теста на работоспособность. В нём я не использовал пока только LoRa модуль. Ссылка на гитхаб: https://github.com/Madjogger1202/Mark_GauntletV4.2/blob/main/src/main.cpp

Дальнейшее создание этой версии будет уже в ближайшее время.

/*  Hi stranger, this is main code file for this project  I'm not a 100% programmer, but i can make electronics work,  so i will be grateful if you add any features  it is fully opensource project, so anyone can build stuff based on this code   have a great time reading this badly written working code (^_^) */#include <Arduino.h>      // why not...#include <Wire.h>#include <SPI.h>// i have to make all modules work, so i will use some libraris to make life easier//1) Display.      im using 0.96 oled from china, it is not standart at dimentions, bt i like how it looks in final designs :)#include <Adafruit_GFX.h>#include <Adafruit_SSD1306.h> // Adafruit librari works 50/50, it depends on display driver (yes, they can hava same names, bt diffrent drivers)//2) RGB Led panel.       LEDs 2812 (8-bit panel) #include <microLED.h>//3) NRF24L01+ #include <nRF24L01.h>#include <RF24.h>//4)APDC9960 usefull sensor#include "Adafruit_APDS9960.h"//5) LoRa radio sx1278#include <RH_RF95.h>//6) MPU6050 gyro + acsel#include <Adafruit_Sensor.h>#include <Adafruit_MPU6050.h>//7) MP3 module#include <DFPlayer_Mini_Mp3.h>// first switches connectionint8_t first_sw[8] = { A14, A13, A12, A11, A10, A9, A8, A7 };// second switches connectionint8_t second_sw[8] = { 38, 37, 36, 35, 34, A6, 32, A15 };// buttons connectionint8_t buttons[4] = { A3, A1, A0, A2 };#define LED1 10#define LED2 11#define JOY_X A6#define JOY_Y A5#define POT A4#define LORA_D0 42#define LORA_NSS 43#define LORA_RST 44#define NRF_CSN 40#define NRF_CE 41#define IR_LED 7#define R_LED 4#define G_LED 5#define B_LED 6#define WS_LED 45LEDdata leds[8];microLED strip(leds, 8, WS_LED); #define ORDER_GRB RF24 radio(NRF_CE, NRF_CSN);Adafruit_MPU6050 mpu;Adafruit_SSD1306 display(128, 32, &Wire, -1);Adafruit_APDS9960 apds;volatile bool irqMPU;volatile bool irqAPDC;struct allData{  volatile boolean irqMPU;  volatile boolean irqAPDC;  bool stable;  int8_t x_acs;  int8_t y_acs;  int8_t z_acs;  uint8_t mode;  uint8_t channel;  uint16_t button;    uint16_t potData;  uint16_t joyX;  uint16_t joyY;  uint8_t led1Mode;  uint8_t led2Mode;  uint8_t redLedMode;  uint8_t blueLedMode;  uint8_t greenLedMode;  uint8_t wsLedMode;  }mainData;struct radioData{  bool stable;  int8_t x_acs;  int8_t y_acs;  int8_t z_acs;  uint8_t mode;  uint8_t channel;  uint16_t button;    uint16_t potData;  uint16_t joyX;  uint16_t joyY;} telemetriData;void readMode();void readCh();void readAcs();void readJoy();void readPot();void readButtons();void sendNRF();void sendBL();void sendLoRa();   // will reliase it soonvoid displayInfo();// at all it is possible to create up to 256 diffrent modes,// but if you need more - connect mode counter with channel counter (maybe partly)void n1Mode();void n2Mode();void n3Mode();void n4Mode();void n5Mode();void n6Mode();void n7Mode();void n8Mode();void n9Mode();void n10Mode();void n11Mode();void n12Mode();void acsel(){  mainData.irqMPU=true;}void gesture(){  mainData.irqAPDC=true;}void setup() {  for(int i=0;i<8;i++)    pinMode(first_sw[i], INPUT_PULLUP);  for(int i=0;i<8;i++)    pinMode(second_sw[i], INPUT_PULLUP);  for(int i=0;i<4;i++)    pinMode(buttons[i], INPUT_PULLUP);  pinMode(LED1, OUTPUT);  pinMode(LED2, OUTPUT);  analogWrite(LED1, 10);  analogWrite(LED2, 100);    pinMode(JOY_X, INPUT);  pinMode(JOY_Y, INPUT);  pinMode(POT, INPUT_PULLUP);    pinMode(LORA_D0, OUTPUT);  pinMode(LORA_NSS, OUTPUT);  pinMode(LORA_RST, OUTPUT);    pinMode(NRF_CSN, OUTPUT);  pinMode(NRF_CE, OUTPUT);    pinMode(IR_LED, OUTPUT);  pinMode(R_LED, OUTPUT);  pinMode(G_LED, OUTPUT);  pinMode(B_LED, OUTPUT);    pinMode(WS_LED, OUTPUT);  strip.setBrightness(130);    strip.clear();  strip.show();   strip.fill(mCOLOR(YELLOW));  strip.show();  Serial.begin(115200);  Serial2.begin(9600);  mp3_set_serial(Serial2);  mp3_set_volume(30);  mp3_play (1);  if (!mpu.begin())    Serial.println("Sensor init failed");  if(!display.begin(SSD1306_SWITCHCAPVCC, 0x3C)) { // Address 0x3C for 128x32    Serial.println(F("SSD1306 allocation failed"));    for(;;); // Don't proceed, loop forever  }  display.display();  display.clearDisplay();    display.display();  if(!apds.begin())    Serial.println("failed to initialize device! Please check your wiring.");  apds.enableProximity(true);  apds.enableGesture(true);  radio.begin();                                        radio.setChannel(100);                                 radio.setDataRate     (RF24_1MBPS);                     radio.setPALevel      (RF24_PA_HIGH);                   radio.openWritingPipe (0x1234567899LL);                 radio.setAutoAck(false);  attachInterrupt(0, acsel, RISING);  attachInterrupt(1, gesture, RISING);  Serial1.begin(9600);         // bluetooth module connected to Serial1   delay(5000);  mp3_stop ();    }void loop(){ readMode(); readCh(); readAcs(); readJoy(); readPot(); readButtons(); Serial.println(digitalRead(A14)); Serial.println(digitalRead(A13)); Serial.println(digitalRead(A12)); Serial.println(digitalRead(A11)); Serial.println(digitalRead(A10)); Serial.println(digitalRead(A9)); Serial.println(digitalRead(A8)); Serial.println(digitalRead(A7)); Serial.println(); Serial.println();   displayInfo();  switch (mainData.mode)  {  case 0:    n1Mode();    break;  case 2:    n2Mode();    break;  case 3:    n3Mode();    break;  case 4:    n4Mode();    break;    }}void readAcs()      // reading acseleration values from sensor directly to main struct{  sensors_event_t a, g, temp;  mpu.getEvent(&a, &g, &temp);  mainData.x_acs = a.acceleration.x;  mainData.y_acs = a.acceleration.y;  mainData.z_acs = a.acceleration.z;  return;}void readJoy()     // i am filering analog values for better perfomance {  mainData.joyX = (analogRead(JOY_X)+analogRead(JOY_X)+analogRead(JOY_X)+analogRead(JOY_X))/4;  mainData.joyY = (analogRead(JOY_Y)+analogRead(JOY_Y)+analogRead(JOY_Y)+analogRead(JOY_Y))/4;  return;}void readPot(){  mainData.potData = analogRead(POT);  return;}void readButtons()   // buttons : 1) 1; 2)0; 3)1; 4)1;   and mainData.button == 1011 {  mainData.button = !digitalRead(A1)*1000+!digitalRead(A2)*100+!digitalRead(A3)*10+!digitalRead(A0);  return;}void sendNRF(){  // i am writing telemetri struct only when sending data  // in this case i can track how relevant telemetri data is  telemetriData.stable = mainData.stable;  telemetriData.x_acs = mainData.x_acs;  telemetriData.y_acs = mainData.y_acs;  telemetriData.z_acs = mainData.z_acs;  telemetriData.mode = mainData.mode;  telemetriData.channel = mainData.channel;  telemetriData.button = mainData.button;    telemetriData.potData = mainData.potData;  telemetriData.joyX = mainData.joyX;  telemetriData.joyY = mainData.joyY;  radio.write(&telemetriData, sizeof(telemetriData));}void sendBL(String inp){  Serial1.print(inp);  return;}// void sendLoRa();void displayInfo(){  display.clearDisplay();  display.setTextSize(1);               display.setTextColor(WHITE);         display.setCursor(0, 0);              display.print(mainData.channel);      display.print("  ");            display.print(mainData.mode);  display.print("  ");  display.println(mainData.z_acs);        display.print(mainData.button);  display.print("  ");  display.print(mainData.joyX);  display.print("  ");  display.print(mainData.joyX);  display.print("  ");  display.println(mainData.potData);  display.display();}void readMode(){  bitWrite(mainData.mode, 0, (!digitalRead(A14)));  bitWrite(mainData.mode, 1, (!digitalRead(A13)));  bitWrite(mainData.mode, 2, (!digitalRead(A12)));  bitWrite(mainData.mode, 3, (!digitalRead(A11)));  bitWrite(mainData.mode, 4, (!digitalRead(A10)));  bitWrite(mainData.mode, 5, (!digitalRead(A9)));  bitWrite(mainData.mode, 6, (!digitalRead(A8)));  bitWrite(mainData.mode, 7, (!digitalRead(A7)));  return;}void readCh(){  bitWrite(mainData.channel, 0, digitalRead(second_sw[0]));  bitWrite(mainData.channel, 1, digitalRead(second_sw[1]));  bitWrite(mainData.channel, 2, digitalRead(second_sw[2]));  bitWrite(mainData.channel, 3, digitalRead(second_sw[3]));  bitWrite(mainData.channel, 4, digitalRead(second_sw[4]));  bitWrite(mainData.channel, 5, digitalRead(second_sw[5]));  bitWrite(mainData.channel, 6, digitalRead(second_sw[6]));  bitWrite(mainData.channel, 7, digitalRead(second_sw[7]));  return;}void n1Mode(){  sendNRF();  digitalWrite(LED1, !digitalRead(LED1)); // just blink to understand, that it is working}void n2Mode(){}void n3Mode(){}void n4Mode(){}void n5Mode(){}void n6Mode(){}void n7Mode(){}void n8Mode(){}void n9Mode(){}void n10Mode(){}void n11Mode(){}void n12Mode(){}

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

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

Сначала я планировал привести в порядок только механику и визор, но в процессе работы понял: я хочу сделать его не таким как все выделить на фоне остальных 1 715 677 Зорких-4, выпущенных за 17 лет на КМЗ!

Механика и оптика

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

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

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

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

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

Как итог все стало крутиться и взводиться мягко и плавно, механизмы задержки работают исправно, будто только вчера купили!

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

Однако не обошлось без поломок:

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

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

Напрашивается вывод: враг ремонта фотокамер глупость и пружинки!

во второй части расскажу о внешнем виде...

Здравствуй, Хабровчанин!
Эта публикация - продолжение статьи "Экстренная психологическая помощь | Prototyping Weekend". Статья повествует о создании Онлайн службы Скорой Психологической Помощи в рамках хакатона, который был организован пражским хакерспейсом Brmlab. Этот мой первый опыт в качестве product owner и full stack developer.

<< ВВЕДЕНИЕ >>

- Что такоеGoto Help?
- Служба экстренной психологической помощи или горячая видео-линия с психологом, доступная на любых устройствах без установки.

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

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

От других проектов мы отличаемся тем, что предоставляем именно ЭКСТРЕННУЮ помощь, консультацию в момент обращения через видео-чат.

Вот примерный круг запросов:
- человек стал свидетелем насилия
- пережил насилие
- получил физическую травму
- вышел из СИЗО

- Как получить психологическую помощь?
- Следуйте инструкции на сайте!

• Шаг 1:Определите, что с вами произошло.

• Шаг 2:Нажмите на соответствующую кнопку в секции "Получить помощь", ожидайте запуска видео-конференции

• Шаг 3:Разрешите видео-конференции использовать микрофон и видео-камеру, после этого ожидайте специалиста.

<< ЧТО НОВОГО? >>

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

1) Переосмысление процесса обработки заявок на получение экстренной психологической помощию.

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

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

На бекэнеде происходит определения типа заявки и нотификация специалистов, которые выбрали для обработки конкретный тип заявки: паническая атака, пережил/а насилия и т.д.

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

2) Переработка архитектуры и технологического стэка платформы.

Было: Google Meet, Google SpreadSheet, Google AppsScript, ChromeExtension, Boostrap 4.
Читать тут "Экстренная психологическая помощь | Prototyping Weekend".

Стало: Python, Nodejs, Jitsi Meet, AWS, GCP, Boostrap 5, Telegram Bot API.
Две облачные гугл функции составляют основу логики. Одна функция рисует веб страничку.

Вторая функция обрабатывает заявки от людей: создаёт новые конференции на платформе Jitsi, посылает их ссылки в Телеграм чат [живые заявки], в публикации отмечает специалистов, которые согласились обрабатывать конкретный тип заявки.

2) Формирования сообщества "психологов - волонтёров".

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

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

Более 10% специалистов откликнулись. Далее была собрана команда специалистов для организации процесса отбора новых волонтёров.

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

В Телеграме было создано два чата:

[штаб] - чат для общей коммуникации участников проекта, баг-репортов и апдейтов.

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


3) Интеграция платформы Goto Help в существующие инициативы.

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

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

4) Обработка первых живых заявок на экстренную психологическую помощь.

От идеи до оказания первой психологической помощи через платформу прошло три месяца.

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

Хочу поблагодарить Всех, кто присоединился к проекту и только собирается это сделать.

5) Что дальше?

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

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

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

В 2020 году на отборочных соревнованиях Цифрового прорыва, крупнейшего в России командного соревнования специалистов в ИТ-сфере, выступили более 45,5 тысяч россиян из 85 регионов. 1249 специалистов вышли в финал, по итогам которого победили 45 команд.

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

Особо следует отметить победителей гранд-финала, в котором команды разделили общий призовой фонд в 22,5 млн рублей. Также они представили свои проекты перед топ-менеджерами корпораций и руководителями федеральных ведомств результаты этих презентаций станут известны на следующий день. Цифровой прорыв флагманский проект президентской платформы Россия страна возможностей. Гранд-финал определил 13 цифровых разработок для совместной реализации с партнерами конкурса. Участники еще шести команд получили предложения по трудоустройству и приглашения на стажировки.

7 ПРИЧИН УЧАСТВОВАТЬ В ЦИФРОВОМ ПРОРВЕ В 2021 ГОДУ

Участие в Цифровом прорыве в 2021 году позволит Вам:

• Научиться работать в команде;

• Обрести новые знания/специализацию, повысить компетенции;

• Найти новых друзей;

• Побороться за денежные призы;

• Реализовать интересные Вам кейсы, которые могут изменить жизнь тысяч людей;

• Найти работу или получить интересные предложения;

• Превратить MVP в полноценный стартап, реализация которого поможет Вам открыть свой бизнес.

Мы ждем тебя наЦифровом Прорыве 2021уже в апреле!

Немного о проекте

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

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

• Шифр Цезаря

• Шифр Виженера

• Шифр замены

• Омофонический шифр

• RSA шифрование

Шифр Цезаря

Итак, после небольшого введения в цикл, я предлагаю все-таки перейти к основной теме сегодняшней статьи, а именно к Шифру Цезаря.

Что это такое?

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

Какими особенностями он обладает?

У Шифра Цезаря, как у алгоритма шифрования, я могу выделить две основные особенности. Первая особенность - это простота и доступность метода шифрования, который, возможно поможет вам погрузится в эту тему, вторая особенность - это, собственно говоря, сам метод шифрования.

Программная реализация

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

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

alfavit =  'ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZАБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЬЭЮЯАБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЬЭЮЯ'# Создаем алфавит

Далее, нам нужно обозначить программе шаг, то есть смещение при шифровании. Так, например, если мы напишем букву "а" в сообщении, тот при шаге "2", программа выведет нам букву "в".

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

smeshenie = int(input('Шаг шифровки: '))    #Создаем переменную с шагом шифровкиmessage = input("Сообщение для шифровки: ").upper()    #создаем переменнную, куда запишем наше сообщениеitog = ''    #создаем переменную для вывода итогового сообщения

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

for i in message:    mesto = alfavit.find(i)    #Вычисляем места символов в списке    new_mesto = mesto + smeshenie    #Сдвигаем символы на указанный в переменной smeshenie шаг

Далее, мы создаем внутри нашего цикла условие if , в нем мы записываем в список itog мы записываем наше сообщение уже в зашифрованном виде и выводим его:

if i in alfavit:        itog += alfavit[new_mesto] # здесь мы прибавляем значение правого операнда к левому    else: # и присваиваем эту сумму левому операнду.        itog += iprint (itog)

Итоговый вид программы

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

alfavit =  'ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZАБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЬЭЮЯАБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЬЭЮЯ'smeshenie = int(input('Шаг шифровки: '))message = input("Сообщение для ДЕшифровки: ").upper()itog = ''for i in message:    mesto = alfavit.find(i)    new_mesto = mesto + smeshenie    if i in alfavit:        itog += alfavit[new_mesto]    else:        itog += iprint (itog)

Дешифровка сообщения

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

По сути, дешифровка - это алгоритм обратный шифровке. Давайте немного переделаем наш код (итоговый вид вы можете увидеть выше).

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

alfavit =  'ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZАБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЬЭЮЯАБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЬЭЮЯ'smeshenie = int(input('Шаг шифровки: '))message = input("Сообщение для ДЕшифровки: ").upper()    #заменяем слово шифровка, на дешифровкаitog = ''

Остальное можно оставить так же, но если у вас есть желание, то можете поменять названия переменных.

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

Итог

Вы успешно написали алгоритм шифровки и дешифровки сообщения на Python с помощью метода Цезаря. В следующей статье мы с вами рассмотрим Шифр Виженера, а также разберем его реализацию на Python, а пока я предлагаю вам написать в комментариях варианты модернизации программы(код или просо предложения и пожелания). Я обязательно учту ваше мнение.

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

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

С другой стороны, совсем без инструментов, документации и дедлайнов справиться с проектом не получится. Это Дмитрий Ильенков из Project Management Club и автор канала @pmclub на конференции TeamLead Conf 2020 наглядно показал в своем выступлении. И там же познакомил нас с p3express с простым фреймворком для проектов любого размера. Этот минималистичный, но системный фреймворк для управления проектами предлагает 37 понятных шагов от идеи проекта до работы с выгодами по его завершению.

Большинство проектов, с которыми мы встречаемся практически каждый день, начинаются очень невинно с небольшой задачки, может быть, даже с просьбы:

Ты был на TeamLead Conf? Поделись, пожалуйста, с командой инсайтами!

Можешь помочь обновить сайт?

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

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

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

Этому есть несколько причин.

Проекты проходят мимо радаров

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

Много букв

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

Я очень люблю PMBOK, и я PMP. Я был президентом Московского Chapter PMI. Но шестой PMBOK это 700 страниц, это реально много. Во-первых, ты их и сам не прочитаешь, а во-вторых, ты не заставишь, а тем более не убедишь прочитать их команду. А в-третьих, кто хочет для небольшого проекта использовать 700 страниц проектной методологии? Есть желающие? Обычно не находятся.

Нам уже было больно

Третья проблема: к вам в компанию приходили консультанты по управлению проектами? Я за последние полгода два раза столкнулся с абсолютно одинаковой историей в двух разных компаниях. К ним приходили консультанты, писали методологию и десятка полтора шаблонов.Люди пробовали заполнить эти 15 шаблонов, но даже 15 шаблонов это очень много. Им было больно, у них не получилось, им не понравилось. Они теперь ходят и рассказывают: проектное управление не работает! Хотят ли они попробовать еще раз? Спасибо, нет.

Возникает вопрос:

Что делать?

Что делать, чтобы управлять проектами как проектами, чтобы использовать лучшие практики и понятную канву, которую придумали до тебя, которая будет работать на тебя и которая будет работать еще дальше, когда ты ее адаптируешь?

Решением будет использовать более простые решения. Тот же самый PMI, правообладатель того самого PMBoK, у которого в шестой версии 700 страниц, в стратегии 2.0 прямо написал: Пришло время легковесных фреймворков. Седьмой PMBoK (я сейчас пишу к нему комментарии), который, надеюсь, выйдет в этом году, в части стандарта занимает только 37 страниц чувствуете разницу? Проще нужно, проще!

И я хочу рассказать как раз о простом, но при этом системной фреймворке, который придумали мои партнеры Надер Кей Рад (Nader K Rad) и Фрэнк Тёрли (Frank Turley). Надер как раз в числе авторов этого короткого классного PMBoK.

p3express

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

В чем его фишка?

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

В управлении проектами этого категорически не хватало до сих пор. Даже мой любимый PMBoK или очень красивый британский PRINCE2 никогда ни в одном месте не отвечают тебе на простой вопрос: что нужно делать завтра? Они пишут, что лучше делать так, есть принципы и процесс, следуй процессу, но завтра мне что сделать?

p3express это пошаговый алгоритм:

• Последовательно проходим 37 шагов, начиная от подготовки;

• Заходим в циклы, в которых работаем

• Выходим на закрытие проекта

• И дальше к пост-проектным активностям, когда извлекаем выгоды:

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

Контекст имеет значение, поэтому наполнение вы адаптируете сами. За счет этого p3express становится одновременно:

• Тиражируемым есть понятная система, ты берешь и переносишь ее;

• Адаптируемым за счет универсальности он подходит к проектам любого размера: от совсем небольших до более крупных.

Пройдем по шагам от начала до конца и посмотрим, 37 шагов это много или мало? Спойлер: немного.

Подготовка проекта

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

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

А01. Определить спонсора

Подготовка начинается с того, что мы определяем, кому этот проект вообще нужен. В проектном менеджменте есть спонсор (куратор) проекта это человек, который заинтересован в результатах проекта и готов на него выделять ресурсы, не обязательно деньги. Это могут быть еще компетенции, экспертизы, какие-то связи. Это может быть кто-то из топов вашей компании или product owner. Главное, чтобы этому человеку нужны были результаты проекта и он был готов в него вкладываться не каждый день работать в проекте, но вкладываться и поддерживать его.

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

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

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

Третьей причиной (из-за которой лично мне больно) бывает то, что приходишь в компанию и спрашиваешь, есть ли у ваших проектов спонсор? Они отвечают: Да! У всех наших проектов есть спонсор. Это генеральный директор. У меня была своя история, когда я на эту ловушку попался. Я презентовал проект руководству компании, проект одобрили и даже дали подразделение в придачу. Я подумал все круто! А через какое-то время мне влетело еще несколько проектов, на меня повесили кучу рутины, а замруководителя, который меня курировал, сказал: Оставьте себе этот проект как хобби. Я посмотрел, как проект чахнет и ушел.

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

А02. Составить резюме

Здесь мы отвечаем на очень простые вопросы:

• Что мы хотим получить в результате проекта?

• Зачем это нам нужно?

• Сколько у нас есть на это времени и денег?

• Что может пойти не так? Другими словами какие риски могут возникнуть.

Ответы на эти вопросы мы упаковываем в простой одностраничный документ это и называется резюме проекта. И эти ответы дают нам понятную пользу: задают вектор проекта и его границы.

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

А03. Определить лидера проекта

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

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

А04. Развернуть рабочее пространство

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

А05. Определить команду

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

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

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

А06. Планирование проекта

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

Здесь же мы продолжаем работать с рисками. Не забывайте про выявление рисков (они вам обязательно встретятся) и про план, как мы будем реагировать на них.

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

А07. Определить внешних исполнителей

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

А08. Провести аудит подготовки

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

И первое в здоровом проекте это чек-лист Аудит подготовки. Перед тем, как принять окончательное решение запускаем проект! ответьте на несколько простых вопросов:

• У нас есть резюме проекта?

• Оно доступно команде?

• Мы развернули рабочее пространство?

• У членов команды есть доступ?

Шаблоны вопросов предлагает p3express, но вам нужно их адаптировать под себя, чтобы они принесли реальную пользу.

А09. Да/нет

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

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

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

А10. Провести kick-off

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

А11. Фокусированная коммуникация

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

Не надо партизанить, коммуницируйте о проекте с теми, к кому он может относиться.

Циклы

Закончив с подготовкой проекта, переходим в циклы, где мы делаем работу. По сути, циклы это аналог того же спринта в Scrum. Каждый цикл начинается с планирования.

Планирование цикла

А12. Обновить планы

Мы провели небольшой опрос в Telegram: из 180 тимлидов около 30% назвали главным своим челленджем в ушедшем году постоянную смену приоритетов.

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

А13. Определить внешних исполнителей

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

А14. Да/нет

Каждый месяц отвечайте на вопрос: нужно ли продолжать проект? Мы иногда забываем, когда следует закончить проект. Один ответ очевиден мы все сделали, передаем результаты своей работы. Но бывают другие причины для остановки и закрытия проекта. Например, он утратил свою актуальность, изменилась ситуация в компании или изменилась ситуация на рынке. Зачем продолжать тратить ресурсы, если их можно переключить на что-то более полезное?

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

Итак, если решение положительное, то переходим к следующим шагам.

А15. Провести kick-off цикла

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

А16. Фокусированная коммуникация

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

Еженедельные действия

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

А17. Оценить прогресс

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

Что нужно проверить?

1. Метка-статус vs комментарии. Проверьте, соответствует ли метка-статус комментариям к продукту. Противоречий быть не должно. Для наглядности и простоты вы можете, например, использовать цветовые метки: зелёная продукт готов, жёлтая продукт в работе, красная продукт не готов/проблема с продуктом.

2. Результаты vs контрольные точки. У вас могут быть контрольные точки как по всему проекту, так и по элементам конфигурации проекта. Проверьте, все ли точки пройдены вовремя? Вы не пропустите важный дедлайн?

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

4. Сопоставьте прогресс с другими проектами. Вы работаете не в вакууме: какие-то отставания критичны, а какие-то нет, если в связанных проектах всё стоит.

5. Слушайте, что говорят. Слухи расходятся быстро, и в них может быть правда. В рабочем пространстве всё идеально, а коллеги сочувственно смотрят в вашу сторону? Что-то идёт не так.

А18. Работать с отклонениями

Работаем с найденными отклонениями (если требуется наше активное участие):

1. Убедитесь, что вы собрали полную и достоверную информацию;

2. Проранжируйте проблемы по важным для вас критериям например, срочность/критичность;

3. Выберите наиболее острые проблемы;

4. Соберите дополнительную информацию;

5. Решайте проблемы на своем уровне или выносите их на уровень спонсора;

6. Помните, ваша задача решить проблему, а не найти крайних.

А19. Еженедельная встреча

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

А20. Еженедельный аудит

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

А21. Фокусированная коммуникация

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

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

Сделано? Сделано. ОК.

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

Такие звонки у нас длились полчаса максимум, и 15 минут из этого времени уходили на Как дела? Мы так рады с вами работать! все эти американские любезности. То есть мы успевали всё обсудить за 15 минут. После созвона лидер проекта направлял коммуникацию команде, что происходит в части работы с этим подрядчиком.

Это действительно идеальная история, и каждая может быть такой. Почему так обычно не получается? Да потому что проблема возникает на этапе получения информации. Информация о проекте, которой мы располагаем, часто бывает не релевантной. Вопрос как мы ее измеряем, как ее визуализируем, что используем (метод освоенного объема, диаграмма сгорания, еще что-то) это вторичный вопрос. Важнее вопрос: насколько мы и команда делаем работу над проектом прозрачной, насколько у нас постоянно есть доступ к этой информации? Все любят пользоваться таск-трекером на словах. На деле разные ситуации бывают.

Почему мы плохо пользуемся такими инструментами?

1. Один вариант команда не понимает, как ими пользоваться технически. По дефолту нельзя рассчитывать, что все всё понимают, все прочитали инструкцию. Нет, людям нужно помочь и немножко их обучить.

2. Второй вариант люди не очень понимают, зачем это надо. Тоже можно объяснить.

3. Третья ситуация смешнее и страшнее. Я ее наблюдал сам.

Вице-президент компании решил всех перевести на Trello. Сначала он говорил про прозрачность, потом про контроль, но начал очень бодро! Он выбрал команду, которая действительно эффективно работала и эффективно пользовалась Trello не просто досочкой в три столбца, у них все было классно. Он попросил лидера этой команды всем показать, как работать в Trello. Лидер команды действительно показал, провел даже не митап, а небольшое обучение. Он пошел на шаг дальше и объяснил, зачем это нужно, как хорошо управлять проектами, он вообще молодец!

Но вице-президент на эту встречу не пришел это был первый звоночек. Второй звоночек был, когда его помощник нам сам создал доски и направил туда приглашения. Через пару недель вице-президент спрашивает: А что вы не ведете ваши доски?, но сам при этом так и не зарегистрировался в Trello.

Убедитесь, что вы посылаете команде правильные сигналы, что это не история: Не живи, как живет учитель. Живи, как учит жить учитель подавайте личный пример.

Ежедневные действия

Это даже не шаги, а рекомендации к ежедневным действиям. Каждый день мы сталкиваемся с какими-то новыми задачами, проблемами и рисками. RICs это риски, проблемы, запросы на изменения. Тот же наш опрос тимлидов показал, что одна из проблем это постоянно прилетающие новые задачи. И это неизбежно.

Что можно делать?

А22. Зафиксировать RICs

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

А23. Реагировать на RICs

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

А24. Принять готовые продукты

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

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

А почему возникает мультизадачность? Это происходит не только потому, что нам постоянно прилетают новые задачи, но и потому что мы не закрываем старые.

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

Принимайте результаты работы как можно чаще!

Закрытие цикла

Каждый цикл мы открываем и закрываем.

Закрытие цикла состоит из трех шагов:

А25. Оценить удовлетворённость заказчика и команды

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

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

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

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

А26. Запланировать улучшения

Прогресс сам по себе не придет. Нужно понять, где можно работать лучше, что для этого нужно сделать.

А27. Фокусированная коммуникация

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

Закрытие проекта

А28. Передать продукт

Вы уверены, что передавая продукт, вы его передаете правильным людям? Со мной случилась (к счастью, это было давно) очень забавная история. Компания, где я работал, решила внедрить довольно дорогую систему бизнес-аналитики. Купили 5 лицензий.

Результат:

• Сколько из них пошли пользователям? Всего одна, две отдали айтишникам, две топам.

• Сколько человек обучили пользоваться этой системой? Одного из айтишников (самого хитрого). Он стал носителем сверх-знаний и не потерялся через полгода стал начальником отдела по работе с этой системой.

Система, кстати, все равно не взлетела, потому что это криво: я пользователь, а у меня нет ни лицензии, ни навыков работы.

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

А29. Передать проект

Проект нужно передавать так же, как и продукт. Проект может быть закончен для лидера проекта и для команды, если это временная команда. Но компания просто выбросила деньги, чтобы вы собрались, что-то сделали и ушли? Тогда проще было заказать. А что с извлеченными уроками? Что с поддержкой продукта, который вы создали? Что с тем же самым заказчиком кто будет продолжать контакт?

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

И в идеале именно этот человек проходит следующие шаги.

А30. Оценить удовлетворённость заказчика и команды

Последний раз оценивается удовлетворенность заказчика и команды.

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

А31. Провести аудит проекта

В целом оценивается эффективность управления проектом.

А32. Извлечь уроки

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

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

А33. Отметить окончание проекта

Можно сколько угодно говорить про выгорание, но если человек приходил на работу, делал-делал проект, не спал ночами и, завершив проект, пошел домой, поспал, вернулся и у него новый проект это похоже на день сурка, причем паршивый день сурка. Не надо этого допускать. Умейте радоваться жизни Work Hard & Play Hard, отмечайте с командой все достижения, а окончание проектов тем более.

А34. Фокусированная коммуникация

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

После проекта

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

А35. Оценить полученные выгоды

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

Мы об этом часто забываем. В презентациях часто красиво написано: Внедрение CRM сократит ваши расходы на отдел продаж на 100%! Мы сократим расходы на ФОТ!. Подождите, сокращение расходов на ФОТ это значит, кого-то уволили. Это называется disbenefits то, что для кого-то хорошо, для кого-то плохо.

А36. Спланировать дополнительные действия

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

А37. Фокусированная коммуникация

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

• По мотивации;

• По улучшению проекта. Люди должны понимать, что от них ожидают;

• По борьбе с бесполезными проектами.

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

Измеряйте выгоды, коммуницируйте!

Выводы

Мы прошли все 37 шагов это оказалось не так много. И они все уместились на доске в нескольких колонках:

Я действительно люблю p3express. Мне нравится, что им просто пользоваться, что я могу пользоваться им не один, а управлять проектом вместе с командой, потому что объяснить, как это делать в p3express достаточно просто.

Пробуйте p3express на небольших проектах в вашей компании, пробуйте на своих pet-project, пробуйте масштабировать, раскатывать и помогать другим.

Simplicity is the ultimate sophistication!

Московская конференция TeamLead в этом году пройдет 29 и 30 апреля в Radisson Slavyanskaya. На конференции будет огромное количество информации, общения, обсуждений для тимлидов команд любых размеров и направлений. Не только для IT-сферы, не только для больших корпорация или маленьких старпапов. О том, как строить (и перестраивать) культуру в компании, как развиваться самому и помогать в этом команде, как решать конфликты для всех с профитом, про бизнес-процессы, коммуникацию, карьеру и многое другое вы получите максимальную концентрацию тимлидского опыта на чел/час и кв.м.

Расписание конференции уже готово.Билеты уже в продаже. Можно участвовать как онлайн, так и по старинке, общаясь вживую. Присоединяйтесь!

Но если вы хотите еще и выступить, на питерскую конференцию Saint TeamLead Conf 2021 еще открыт прием докладов. Мы помогаем спикерам во всех вопросах выступления, в том числе учим выступать и как подготовить презентацию. А в Программном комитете ваши заявки просматривают и отбирают опытные спикеры, неоднократно выступавшие на разные темы и эксперты в своих направлениях. Выходите на свет рампы вместе с нами!

Термин бережливого производства (Lean) в настоящее время на слуху. Мы все знаем результаты применения данной идеи в компании Toyota, которые позволили выпускать малые партии комплектующих точно в срок (Just-In-Time, JIT).

В книге Microsoft Secrets (1995 года) авторы (Кузумано и Ричард Селби) описали подходы контроля качества схожие с Lean применяемым в Toyota.

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

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

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

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

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

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

Отправная точка

Изначально в команде применялась несколько упрощенная методология Scrum. Ниже приведу ее описание.

Набор артефактов:

1. Project backlog журнал требований, реализуемых в рамках проекта, обнаруженные в процессе эксплуатации инциденты. Обычно требования оформляются в виде User Story. В качестве инструмента для верхнеуровневого планирования использовали Excel. Там же, для удобства, чтобы все было в одном месте, на отдельной странице сделали диаграмму Ганта и диаграмму сгорания.

2. Sprint backlog журнал требований и инцидентов реализуемых за спринт.

3. Scrum-доска. В качестве инструмента использовали доску Trello с расширением Plus For Trello для контроля трудоемкости.

Роли в команде:

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

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

3. Команда разработчиков состоит из опытных разработчиков и новичков, которые повышают свои компетенции в процессе участия на проекте.

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

Совещания:

1. Ежедневный митинг команды.

2. Ретроспектива в конце спринта.

3. Ежеквартальные ретроспективы.

Параметры спринта:

1. Продолжительность: 1 месяц.

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

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

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

Хьюстон, у нас проблемы

Явные проблемы заметили на втором месяце этапа ОПЭ (опытно-промышленной эксплуатации), когда новые требования по дефектам начали закрывать время затраченное на запланированные дефекты и пожелания. Фактически мы стояли на месте. Вероятность успеха сделать все вовремя стремилась к 0.

Для исправления ситуации было решено провести экстренную ретроспективу и собрать все существующие проблемы.

Удалось выявить следующие точки улучшения:

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

2. Недостаточное качество итогового кода, требуется повысить контроль качества.

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

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

5. Много времени уходит на разработку и доработку, консультанты простаивают.

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

А что думает заказчик? Заказчик недоволен динамикой реализации требований. Но готов рассмотреть вариант с четким и прогнозируемым планом.

Именно в этот момент появилась идея использовать подход JIT для улучшения текущей ситуации.

Какие преимущества Agile-Lean мы попробуем использовать в нашем проекте

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

Сильные стороны:

1. Получение результата в ограниченное время.

2. Устранение ненужных действий, которые могут снизить стоимость.

3. Расширение прав и возможностей команды разработчиков, помогающих им принимать решения.

4. Гибкость проекта, возможность его корректировки под требования заказчика.

Слабые стороны:

1. Большие требования к вовлеченности команды в процесс.

2. Строгая документация, что несколько противоречит принципам Agile, когда продукт важнее документации.

3. Необходимость детального планирования перед каждым спринтом.

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

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

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

Адаптируем 7 принципов Lean

Согласно методологии Lean для разработки программных продуктов, выделяется 7 основных принципов:

• Исключение потерь. Потерями считается все, что не добавляет ценности для потребителя: излишняя функциональность; ожидание (паузы) в процессе разработки; нечеткие требования; бюрократизация; медленное внутреннее сообщение.

• Акцент на обучении. Короткие циклы разработки, раннее тестирование, частая обратная связь с заказчиком.

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

• Предельно быстрая доставка заказчику. Короткие итерации.

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

• Интегрирование. Передать целостную информацию заказчику. Стремиться к целостной архитектуре. Рефакторинг.

• Целостное видение. Стандартизация, установление отношений между разработчиками. Разделение разработчиками принципов бережливости. Мыслить широко, делать быстро, ошибаться мало; учиться стремительно.

Проанализировав принципы, сформировали 7 своих, которые подошли к нашей текущей ситуации и должны были помочь закрыть существующие проблемы:

1. Убрать ненужное

Под ненужным будем понимать следующее:

1. Все, что не приносит пользы конечным пользователям. Сюда относятся непонятные и несрочные требования, редко проявляющиеся дефекты. Мы их откладываем или отказываемся вовсе после согласования с заказчиком.

2. Ненужный код, дублирование кода.

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

4. Программные дефекты. Любые дефекты появляются, когда код не проходит достаточную проверку качества.

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

Что мы сделали, чтобы решить задачу:

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

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

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

4. Формирование задач из набора требований в рамках одного реализуемого процесса. Расчет: разработчик загружен на одну задачу не менее 8 часов.

2. Создавать знания и обмениваться ими

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

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

3. Повышение качества кода

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

Для повышения качества были приняты следующие предложения:

1. Парное программирование. Непосредственное взаимодействие тимлида с разработчиками, совместный анализ требований, проектирование, решение сложных задач.

2. Степень готовности (Definition of Done, DoD). Задача считается завершенной только в том случае, когда разработчик обсудил реализацию с тимлидом и провел демонстрацию разработанной функциональности консультанту, который закреплен за данной задачей.

3. Максимальное количество задач в работе (Work In Progress, WIP) каждого разработчика. У разработчика в работе и в тестировании суммарно не может быть больше 3-ех задач. Если разработчик отправил на тестирование все 3 задачи, то он обязан довести эти задачи до публикации в продуктивную систему, для этого активно взаимодействует с консультантами, отвечает на возникающие вопросы, помогает в процессе тестирования.

4. Сокращение спринтов

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

Поэтому решили сделать ряд ограничений на спринт:

1. Спринт длится 1 рабочую неделю.

2. На спринт планируется трудоемкость, которую сможет закрыть команда разработки (на основе собранной статистики за предыдущие cпринты). Дополнительно закладывается время на устранение критических дефектов.

3. Все реализованные доработки тестируются на специальной копии продуктивной системы с продуктивными данными (PreProd), и только после успешной проверки публикуются на продуктивную среду (Prod).

4. Публикация на продуктивный стенд выполняется только один раз в последний день спринта.

5. После каждого спринта собирается сокращенная ретроспектива на 30 минут для сбора фидбека с команды.

5. Расширение полномочий команды

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

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

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

6. Не торопиться с принятием решений

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

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

7. Регулярная оптимизация процесса

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

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

Для реализации данного принципа с тимлида команды разработки были сняты все задачи по разработке и переданы команде, объем задач на спринт был сокращен, т.к. команда разработки фактически ослабла.

Тимлид команды теперь выступает в качестве наставника:

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

2. Инициирует передачу опыта между разработчиками.

3. Помогает консультантам в формировании требований, а разработчикам в реализации этих требований.

4. Занимается развитием разработчиков и расширением их компетенций.

5. Занимается подбором и развитием инструментария, повышающего эффективность процесса разработки.

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

Основная проблема бережливого производства отодвигание сроков

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

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

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

Итоги

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

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

Но в любом случае необходимо взрастить эксперта среди ваших сотрудников. Он будет сосредоточен на улучшении процесса разработки и мотивирован в повышении своих навыков и навыков команды разработки.

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

1. Обеспечить единую общую среду общения и обмена знаниями.

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

3. Не пренебрегать неформальным общением.

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

По итогам внедрения Lean получили следующие количественные изменения:

1. Скорость разработки стала прогнозируемой и составила примерно 4 крупные задачи (до 6 часов на задачу в среднем) на сотрудника в неделю, ранее мощность команды в среднем составляла до 2-3 завершенных задач в неделю на сотрудника. Да, задачи крупные и это не совсем по Agile, но это помогло в нашей ситуации.

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

3. Уменьшилось вдвое количество задач, возвращаемых на доработку.

4. Еженедельно закрывалось по 3 крупные задачи из техдолга.

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

Данный опыт планируется транслировать на другие проекты компании.

Спасибо за внимание, коллеги! Хотелось бы увидеть в комментариях ваш опыт использования Agile-Lean (или их адаптации) на ваших проектах.

Вступление

Привет, меня зовут Даниил, я студент второго курса радиофака в УрФУ. Сколько помню свое обучение в универе, у нас постоянно продвигалась концепция проектного обучения. Захотелось рассказать, как оно проходит именно с точки зрения студента.

Индивидуальные образовательные траектории

Все предметы делятся на два типа - обязательные и по выбору

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

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

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

Окей, а что такое проектное обучение-то?

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

В начале каждого семестра подготавливается список проектов, которые предлагают компании-партнеры вуза. Студенты выбирают понравившийся им проект, работают над нам в течение семестра и на сессии защищают проделанную работу. Отмечу, что можно придумать свой проект и/или продолжать работать над проектом с прошлого семестра (Если разрешит куратор проектного практикума)

В 2019-2020 годах было прям совсем плохо. После выбора проекта ты оставался с ним на один. Не было четких сроков и задач. Куратор проекта редко появлялся и никак не мог повлиять на развитие проекта. В итоге команды придумывали что-то свое, пилили на коленке за неделю до сдачи и защищали как абсолютно новое инновационное решение.

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

Но, как мне кажется, у проектного обучения в университете есть фундаментальные проблемы.

Проблемы проектного практикума

Постарался расположить в порядке важности

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

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

Третья- нет никакой профессиональной ориентации. Никто не рассказывает о том, какие есть профессии в ИТ и в чем их разница.

Четвертая проблема - нет обмена опытом. После того, как проекты были успешно (или не успешно) закончены, студенты не могут поделиться опытом друг с другом. Из-за этого процесс развития команд сильно замедляется, ведь они повторяют ошибки друг за другом.

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

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

Возможные варианты решения проблем

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

Что нужно сделать:

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

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

Рассказывать о всем многообразии профессий в ИТ. Простого курса видосов на эту тему вполне хватит.

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

Вместо заключения

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

Думаю, что проектное обучение - это движение в правильном направлении.