Русский
Русский
English
Статистика
Реклама

Управление разработкой

Расшифровка эфира с Джоном Ромеро байки о том, как создавался DOOM

29.08.2020 12:21:18 | Автор: admin

10 августа в наших соцсетях прошел стрим с Джоном Ромеро создателем игр Doom, Quake и Wolfenstein 3D. Это был вечер теплых ламповых историй по заявкам: вы задавали вопросы в комментариях, а Джон рассказывал, как все было.

Вопросы задавал автор телеграм-канала и подкаста Запуск завтра Самат Галимов.

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

Тебя знают во всём мире как создателя DOOM и Dangerous Dave. Это очень популярные игры, а какую игру ты создал первой?


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


Ты прогал прямо на настоящем мэйнфрейме с доступом по телетайпу?


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

Это была текстовая игра?


Да, текстовая игра, как Zorg или Adventure.

Разве интересно было играть в собственную текстовую игру? Ты же знал все ответы



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

Кто-нибудь еще играл в неё?


Нет, только я.

Как ты заполучил доступ к этому первому компьютеру?


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

Это было законно или не совсем?


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

Вас кто-нибудь выгонял оттуда?


Нет, ни разу не выгоняли.

У тебя был свой компьютер?


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

Джон, а какую игру ты опубликовал первой?


Она называлась Scout Search, в 1984 году ее напечатали в журнале.

В журнале? Как это?


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

Сколько же это строк кода?


Ну, обычно люди старались делать игры небольшими, так что не длиннее пары сотен строк.

Итак, как мы выяснили, первым компьютером, который ты увидел, был этот мэйнфрейм, а какой был первый нормальный компьютер, на котором ты работал?


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

И сколько удавалось поработать в магазине за один заход? По моему опыту, оттуда довольно быстро выгоняют


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

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


Безусловно, Pac-Man.

Прямо настоящий, на игровом автомате?


Да.

И ты играл за настоящие монеты?


Да, я потратил три года и несколько тысяч долларов на игровые автоматы. Тогда автоматы были повсюду, мир был полон ими. Их больше нет, даже представить невозможно, что автоматы были везде, куда ни глянь. В Pac-Man играло столько народа, что в Японии и США начался дефицит монет.

Давай переместимся на 15 лет вперед и поговорим о DOOM. У DOOM было три создателя: ты, Джон Кармак и Дэйв Тейлор. Как вы все познакомились?


DOOM мы делали впятером: я, Джон, Том, Адриан и Кевин. Мы познакомились, когда работали вместе в компании SoftDisk в 1990 году.

Вы были там программистами?


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

Когда же вы спали?


В два часа ночи ложились спать, а в десять утра возвращались на работу. Так что мы работали с 10:00 до 18:00, а затем принимались за создание новой игры. Работали по 16 часов в сутки.

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


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

То есть, вы, по сути, знали, что сидите на мешке с золотом, но не в денежном смысле, а в смысле создания чего-то выдающегося


Да. Меньше чем за три месяца мы сделали три игры, где использовали эту технологию, а потом выпустили их. Это был Commander Keen. Первая трилогия.

Я должен сознаться, я каждый день играю в нее в DOS-боксе


Если у тебя Mac, можно загрузить Commander Genius это замечательная версия всех игр Commander Keen специально для Mac, но внутри нее изначальная DOS игра.

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

Я знаю, что ты участвовал в работе над демо Super Mario III. Можешь рассказать нам об этом?


Когда мы придумали этот технологический приём, первое, для чего была использована демоверсия, это создание первого уровня Super Mario III, но без использования самого Марио. Мы двигались по миру Марио, а один из моих персонажей, Опасный Дейв, прыгал в этом мире. Это было просто изначальное демо под названием Опасный Дэйв и нарушение авторских прав. Это выглядело потрясающе. Сразу же возникла идея сделать первые два уровня Super Mario III со всеми монстрами, Марио и всем остальным и отправить их в Nintendo. Вот почему мы сделали эту демку чтобы узнать, заинтересована ли Nintendo в издании нашей версии Super Mario III для ПК.

И они, видимо, не были заинтересованы?


Они посчитали, что версия действительно отличная, но решили, что не хотят переносить свою собственность на чужую платформу, поэтому мы сделали Commander Keen.

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


Wolfenstein. Мы сделали Wolfenstein в 1992 году, это был наш третий шутер. До этого у нас было ещё два, они помогли нам отработать технологию и понять, что вообще делают в играх от первого лица. К тому времени, как мы сделали Wolfenstein, мы поняли, что использование оружия делает игру интересной. Сразу после этого мы выпустили приквел к Wolfenstein, Spear of Destiny. Мы сделали его довольно быстро, всего за два месяца. А затем начали планировать DOOM. Технически нужно было всё делать заново, с нуля, потому что мы не могли использовать ничего из Wolfenstein, так как планировали написать совершенно другой движок. Еще до того, как начать работу на DOOM, мы знали, чего сможем достичь в игре, и были очень воодушевлены этим знанием. Мы не думали, что рискуем, потому что знали, какие проблемы надо решить, и знали, что дадим себе столько времени, сколько понадобится на их решение. Получается, создание Wolfenstein от идеи до выпуска заняло четыре месяца, и нас было четверо. После Wolfenstein мы наняли еще двоих. Всего получилось шесть человек, один из которых был бизнес-менеджером и не участвовал в разработке, так что нас было пятеро.

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

Это из-за того, что нарисовать кривую линию сложнее?


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

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

Это очень серьезный прогресс в технологии, он потребовал больших вложений


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

У нас было практически сколько угодно времени. С того момента, как мы выпустили Commander Keen в декабре 1990 года, у нас не было проблем с деньгами. За Commander Keen в первый месяц мы заработали наши первые 10 500 долларов. Через год мы зарабатывали уже 50 000 долларов в месяц, и нас по-прежнему было всего четверо. Понятно, что мы тратили не всё. Мы просто продолжали вкладывать деньги в компанию, но наш банковский счет продолжал расти. Благодаря этому у нас было много времени для создания игр, нам никогда не приходилось ускорять разработку. На разработку Wolfenstein мы потратили четыре месяца, а на создание DOOM ушёл целый год. Когда вышел Wolfenstein, денег стало больше как минимум в пять раз.

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

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

Мы знали, что именно пытаемся сделать. Скажем, с Wolfenstein мы действительно добавили в игру больше, а затем, поиграв в нее, быстро убрали добавленные нами функции, потому что они мешали самой сути игры, а суть была динамичная игра, в которой надо во всё палить. Если приходится останавливаться в коридоре, чтобы обыскать тело, вы останавливаете сущность игры. Игра была весьма скоростной, и это стало сутью. Суть заключалась в том, чтобы стрелять во всё подряд, получать ключи, открывать двери, продолжать во всё стрелять, собирать всё, что видишь, но никогда не останавливать игрока, за исключением момента, когда он добрался до двери, и ему надо ее открыть. Вот, в принципе, и всё останавливаешься только если наткнулся на дверь. Чем больше мы добавляли в игру того, что могло бы замедлить игрока, тем больше мы понимали, что игра не об этом: не о том, чтобы быть незаметным, не о том, чтобы шарить по чужим карманам или таскать трупы. Мы снова всё убрали, потому что суть игры не в этом. Не в том, чтобы перекладывать тела и со всем этим возиться. Она в том, чтобы нестись на всех парах через этот замок со скоростью 70 кадров в секунду и, по сути, мочить всех направо и налево. Мы убрали из игры всё, что этому не соответствовало. С DOOM было то же самое. Пока мы делали DOOM, у нас было много элементов, которые мы потом убрали. В Wolfenstein надо было подбирать предметы, за которые давали очки. Потом мы начали играть в DOOM, и поняли, что это не аркадная игра, не должно быть очков, нас не волнует счет. Нас волнует Твоя задача в том, чтобы убить всех демонов, выбраться с уровня, чтобы перейти на следующий, уничтожить всех демонов там и спасти оставшихся людей. Смысл не в том, чтобы набрать побольше очков. Больше того, DOOM не наказывает игрока за смерть. То есть, тебе не говорят, что у тебя три жизни: их столько, сколько хочешь. Если умираешь, то оказываешься в начале уровня или загружаешься с сохраненной игры и пробуешь снова. Ты не теряешь пройденные уровни, у тебя нет количества жизней, как в аркаде. Так что мы убрали жизни, убрали счёт и все предметы, дававшие очки.

Получается, что не было строгого плана. Всё постоянно пересматривалось. Вы что-то добавляете, потом понимаете, что это не работает, потом


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

Вы проверяли все это на ком-то или принимали решения внутри команды?


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

То есть вы показали её кому-то ещё только перед самым выходом?


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

Их замечания касались только найденных проблем, а не идей, да?


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

Правда, что для создания текстур вы сканировали сапоги из змеиной кожи и содранные коленки? Что там за история с этим?


Да! В DOOM много чего отсканировано и оружие, и Думгай, и Кибердемон, и Барон ада. Все это отсканированные 3d-модели, которые мы создали

Постой-ка, 3d-модели? В девяностые? Ты о чем?


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

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

Все это делалось внутри компании? Все эти ребята сидели там?


Их было только двое, два художника.

Правда, что после выхода DOOM люди увольнялись с работы, бросали университеты, школы, колледжи и целыми днями играли? Это правда?


О да, это был невероятный хит.

Ты не чувствуешь себя виноватым?


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

Вы сами играли после релиза?


Да, постоянно играли.

Но вы ведь сотни раз играли в процессе разработки


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

Значит, игре нет конца


Угу.

Вы сидели в одной комнате или использовали локальную сеть побольше?


У нас в компании была своя сеть, каждый был к ней подключен, так что все могли играть. Это была проводная сеть, поэтому скорость была отличной. Если я хотел поиграть с Шоном [Грином], который сидел за стенкой, в соседнем кабинете, то он просто заходил в игру, мы подключались и звонили друг другу по телефону, чтобы удостовериться, что оба подключены.

По проводному телефону, да?


Ага, по проводному телефону.

Кто играл лучше всех? У вас в компании были чемпионы?


Да, я. У нас было не так много людей, наша компания была очень маленькой. Играли в основном я, Американ [Макги] и Шон [Грин]. Остальные почти не играли. Они играли, только чтобы убедиться, что их текстуры работают правильно, дизайн работает, но смертельный бой их не интересовал. Играло только три человека, потому что всего в компании нас было восемь, включая секретаря девять, включая Американа.

Расскажи о смертельном бое, потому что на твоей вики-странице написано, что ты отец этого слова. Как это случилось?


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

Итак, представим, что сегодня 10 декабря 1993 года. Игра только что вышла. Что ты чувствуешь?


Мы страшно устали, мы работали 30 часов, начали накануне, а загрузили игру в два часа дня. Мы просто Некоторые уже спали, лежа на полу у них кончились все силы. Джей, наш генеральный директор, смог выспаться, потому что он не занимался программированием. Так что он чувствовал себя хорошо и был готов разобраться с загрузкой игры. В два часа дня ее загрузили на ftp-сайт Висконсинского университета и на BBS с программным обеспечением в Массачусетсе, чтобы люди, использующие BBS и модемы, могли загрузить игру оттуда, а пользователи интернета могли скачать ее с университетского сайта. Как только игру выложили, мы все пошли домой спать и проспали до следующего дня. Мы невероятно устали. Но мы знали, что игру ждет успех.

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


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

Всё-таки кое-что ты в финансах понимал


Ага. Кстати, Quake мы выпустили в июне, как только доделали. Это произошло летом, а лето самое плохое время для продажи игры.

Одна из причин огромной популярности DOOM возможность создавать моды


Вам не было страшно? Вы не боялись, что люди создадут что-нибудь безумное?

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

Нужно будет обязательно заценить.


Да, заходите на doomworld.com.

Кстати, перед этим интервью мы связались с самым популярным геймерским сайтом в российском интернете


Он называется Канобу, они подготовили список вопросов путем голосования

Итак, первый вопрос: тебе правда нравится DOOM 2020 и DOOM 2016?


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

Где стримы, Джон? :)


В какой-то момент я ими займусь, но сейчас у меня слишком много дел. Я люблю стримить, последний раз я это делал, когда играл в DOOM Eternal. Часто я говорю с другом по гарнитуре, когда мы играем, так что я взаимодействую с людьми, мое внимание поглощено именно этим. Во время стрима приходится развлекать народ, не хочу на это отвлекаться.

А ты когда-нибудь пробовал просто сосредоточиться на игре и посмотреть, что из этого выйдет?


Наверное, стоит попробовать [смеется].

Ты планируешь какие-нибудь неофициальные дополнения для DOOM 2 или, может, для SIGIL?


Да, SIGIL это эпизод, который я сделал на 25-летнюю годовщину DOOM. Это пятый эпизод DOOM. Круто, что софту он понравился и его официально добавили в DOOM. Так что если у вас есть DOOM на Switch, на айфоне или на приставке, то у вас есть и SIGIL. SIGIL один из редких эпизодов для DOOM I. Обычно дополнения и новые уровни разрабатывают для DOOM II, но в честь юбилея я решил выпустить эпизод для оригинальной версии.

Ещё какие-нибудь дополнения планируешь?


Да! Не могу сказать, что именно я делаю, но планирую кое-что сделать.

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


В основном в Ghost Recon Breakpoint, иногда в Wildlands.

Сколько часов в неделю ты играешь?


Играю где-то раз в неделю по 6 часов вместе с другом. Начинаем где-то в 9 вечера, а заканчиваем в 3 часа ночи или позже.

Будет ли переиздание Daikatana? Текущая версия очень далека от того, что ты планировал изначально


Я не собираюсь перевыпускать Daikatana. Проблема в том, что эту игру практически уничтожили во время релиза еще в 2000 году. Так что 20 лет назад люди просто Столько статей написано о том, насколько она плоха. У нее и в самом деле много недостатков. У этой игры такая плохая репутация, что мне незачем тратить время на ее перевыпуск.

Насколько для тебя важно то, нравится ли твоя игра людям или не очень?


Сколько радости испытываешь от того, что делаешь игру для себя, а сколько от того, что люди в восторге от твоей игры?

В идеале ты делаешь игру для себя и людям она нравится. Если ты вкладываешь много времени и сил в игру, которую любишь, тогда и людям она придется по душе. Когда я делал уровни для SIGIL, мне они очень нравились. Я потратил на них кучу времени, и, когда они вышли, многие были ими довольны.

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


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

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

Скоро выйдет Cyberpunk 2077. В ней показана модель будущего, которое ждет человечество



Что ты, Джон Ромеро, думаешь о будущем игровой индустрии через 30-50 лет?

Ммм, господи Ну, думаю, что-то должно произойти с приставками, потому что телефоны становятся все мощнее, в какой-то момент они заменят приставки. Думаю, что концепция Switch когда у тебя есть портативный девайс, который проецирует игру на большой экран показывает нам, как будут выглядеть игры для тех, кто предпочитает сидеть перед большим экраном с телефоном в качестве контроллера. Возможно, к телефону нужно будет что-то подключить, чтобы можно было быстрее нажимать кнопки. Sony и Microsoft сделают что-то в этом духе. Потому что телефоны настолько мощны, что, возможно, они выпустят телефон, который захочет купить каждый, и он заменит приставку. Ведь телефоны настолько мощные, что могут транслировать сигнал на экран телевизора с помощью беспроводной сети. Так что же делать, если все сидят в телефонах? Мобильные устройства это другой сегмент рынка, новая техника позволяет играть в крутые игры, в которые не поиграешь на телефоне, только потому, что экран слишком маленький. Так что, на мой взгляд, это совсем разные вещи сидеть на диване с контроллером в руках, глядя на большой экран, скажем, в 4K, и сидеть с телефоном, играя во что-то попроще.

Ты играешь в игры с Apple Arcade?


Я подписался на этот сервис, так что кое в какие играю.

Что посоветуешь?


Grindstone, наверное, я в нее еще не играл, но я знаю, что она хороша.

Круто, спасибо, и второй короткий вопрос. У тебя есть Switch?


Да, обожаю Switch. Раньше я много играл в The Legend of Zelda. Мне страшно понравилась Breath of the Wild. Играл в Animal Crossing: New Horizons. Но сейчас у меня мало времени на игры.

Над какими проектами ты сейчас работаешь?


Прямо сейчас работаю над игрой Empire of Sin. Мы разрабатываем ее уже больше трех лет. Она должна выйти в этом году. Можете просто зайти на empireofsingame.com, посмотреть видео и вы увидите, что это стратегия о мафии 1920-х годов.

Ты все еще работаешь по ночам?


Да, конечно [смеется].

Стоит ли ждать от тебя шутер?


Надеюсь!



Если вам не хватило общения с Джоном, можно посмотреть наше предыдущее интервью с Ромеро Упрости и вырежь необходимое, где вопросы задавал управляющий партнер RUVDS ntsaplin



Что было ранее


  1. Илона Папава, Senior Software Engineer в Facebook как попасть на стажировку, получить оффер и все о работе в компании
  2. Борис Янгель, ML-инженер Яндекса как не пополнить ряды стремных специалистов, если ты Data Scientist
  3. Александр Калошин, СEO LastBackend как запустить стартап, выйти на рынок Китая и получить 15 млн инвестиций.
  4. Наталья Теплухина, Vue.js core team member, GoogleDevExpret как пройти собеседование в GitLab, попасть в команду разработчиков Vue и стать Staff-engineer.
  5. Ашот Оганесян, основатель и технический директор компании DeviceLock кто ворует и зарабатывает на ваших персональных данных.
  6. Сания Галимова, маркетолог RUVDS как жить и работать с психиатрическим диагнозом. Часть 1. Часть 2.
  7. Илья Кашлаков, руководитель фронтенд-отдела Яндекс.Денег как стать тимлидом фронтендеров и как жить после этого.
  8. Влада Рау, Senior Digital Analyst в McKinsey Digital Labs как попасть на стажировку в Google, уйти в консалтинг и переехать в Лондон.
  9. Ричард Левелорд Грей, создатель игр Duke Nukem 3D, SiN, Blood про личную жизнь, любимые игры и о Москве.
  10. Вячеслав Дреер, гейм-дизайнер и продюсер игр с 12-летним стажем про игры, их жизненный цикл и монетизацию
  11. Андрей, технический директор GameAcademy как видеоигры помогают прокачивать реальные навыки и найти работу мечты.
  12. Александр Высоцкий, ведущий PHP-разработчик Badoo как создаются Highload проекты на PHP в Badoo.
  13. Андрей Евсюков, заместитель CTO в Delivery Club про найм 50 синьоров за 43 дня и о том, как оптимизировать фреймворк найма

Подробнее..

Как работают и отдыхают ИТ-специалисты в пост-карантин?

09.09.2020 10:06:55 | Автор: admin
В марте из-за пандемии COVID-19 Русфинанс Банк (РФБ) и целый ряд других компаний перешли на дистанционный режим работы. После снятия ограничений многие организации возвращаются к работе в офисе, однако РФБ и его ИТ-подразделение продолжает работать удалённо (подробнее о переходе на удалёнку можно прочитать тут).

Мы решили выяснить, как изменилась работа сотрудников после перехода в home office, и заодно познакомить вас с нашими ИТ-экспертами системными аналитиками, бизнес-аналитиками, разработчиками, тестировщиками.

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

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



Чем ты занимаешься в Русфинанс Банке? За что отвечаешь?

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

До этого работал системным аналитиком, затем руководителем группы.

Опиши, пожалуйста, одним словом/ фразой (метафорой, эпитетом), твой девиз в работе.

Поспешишь людей насмешишь.

Какие гаджеты (компьютеры, планшеты, смартфоны) ты используешь в работе/ для личного пользования? Изменились ли они с переходом на удалёнку?

Рабочий ноутбук + домашний компьютер + смартфон + умные часы. С уходом на удалёнку ничего не поменялось. У меня смартфон Huawei Honor 8, исторически пользуюсь Androidом.

Какие операционные системы тебе нравится использовать вне работы? С какими OS было бы интересно познакомиться для себя? Почему интересны именно они?

Использую Windows 10, на *nix никогда не планировал переходить, так как иногда играю в игры, а в те времена, когда я начинал (~20 лет назад), было немало проблем с совместимостью, поэтому так и остался на Windows. И хотя сейчас хобби уже практически сошло на нет, так как перестало затягивать и цеплять, инерция сохранилась.

Изредка собираемся с друзьями на сессионные игры (аналоги настольных игр типа Armello или MOBA типа Heroes of the Storm). Из однопользовательских игр последними меня зацепили Persona 5, Cuphead, Disco Elysium и Horizon: Zero Dawn.

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

В целом для домашнего пользования мне достаточно Windows.
Скучаю по привычному Windows XP

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

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

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

В рабочем процессе используем Jira. По завершении процесса Discovery (бизнес-анализ, исследование актуальности и окупаемости той или иной фичи) задача заводится в бэклоге Delivery (системный анализ, разработка, тестирование, внедрение). Задачу декомпозируем на подзадачи, берём в работу, включаем в нужный релиз. У типовой задачи будет движение между аналитиком, Oracle-разработчиком, Java-разработчиком, тестировщиком и менеджером приложения (роль, которая в том числе отвечает за внедрение).

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

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

Confluence мы преимущественно используем как базу знаний. Пока вопрос лицензий ещё не решён окончательно. Тем не менее, мы очень надеемся, что сможем собрать в единое удобное для чтения и редактирования место все знания, разбросанные по инструкциям, письмам, головам и так далее. Амбициозно рассчитываю стать одним из основателей процесса управления знаниями в компании (улыбается). Пока мы наполняем базу не слишком активно, так как контрибьютить могут не все участники команды.

Какие фреймворки, языки, IDE и другие инструменты тебе нравится использовать больше всего? Почему?

Сам разработкой не занимаюсь, с кодом работаю в основном в рамках чтения, написания проверочных скриптов. Для этих небольших нужд использую Pl/Sql developer.

Моделированием мы занимаемся не слишком часто, но когда необходимость возникает, использую Visio и Visio-совместимые приложения (например, draw.io).

Какое место в твоей жизни занимает тайм-менеджмент? Какие инструменты/ методики ты используешь для управления своим временем (если есть)?

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

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

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

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

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

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

Какую профессиональную литературу ты читаешь? Что можешь порекомендовать?

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

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

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

Какие полезные профессиональные привычки помогают тебе в работе?

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

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

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

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

Если брать системный анализ, я бы сформулировал два:

1. Всегда старайтесь узнать чуть больше, как в технической, так и бизнесовой части.

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

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

2. Не бойтесь задавать глупые вопросы.

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

*Статистика собрана эмпирическим путём

В целом важные на мой взгляд советы:

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

2. Совет, который мне давали мои руководители ещё в самом начале работы в РФБ, когда я был специалистом, а не менеджером. Тогда я к нему не прислушался, потому что он внутренне показался мне неверным. Я смог по-настоящему его оценить только на дистанции. Хотя обоих советовавших я безмерно уважал и уважаю. И в целом всегда старался следовать всем их рекомендациям.

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

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

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

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

О самоизоляции


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

Перевод Как использовать простую утилиту для поиска уязвимостей в программном коде

01.09.2020 10:05:42 | Автор: admin
Graudit поддерживает множество языков программирования и позволяет интегрировать тестирование безопасности кодовой базы непосредственно в процесс разработки.


Источник: Unsplash (Markus Spiske)

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

Очевидно, что в современных реалиях разработки программного обеспечения важно обеспечить безопасность процессов. В своё время был даже введён специальный термин DevSecOps. Под этим термином понимают ряд процедур, направленных на выявление и устранение уязвимостей в приложении. Существуют специализированные open source решения для проверки уязвимостей в соответствии со стандартами OWASP, которые описывают различные типы и поведение уязвимостей в исходном коде.


Существуют разные подходы к решению проблем безопасности, например, статическое тестирование безопасности приложений (SAST), динамическое тестирование безопасности приложений (DAST), интерактивное тестирование безопасности приложений (IAST), анализ компонентов программного обеспечения (Software Composition Analysis) и так далее.

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

Я остановлюсь на статическом анализе кода и воспользуюсь простым open source инструментом, чтобы продемонстрировать всё на практике.

Почему я выбрал open source инструмент для статического анализа безопасности кода


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

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

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

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

Использование Graudit для анализа безопасности кода


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

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

Существуют похожие инструменты для статического анализа кода Rough Auditing Tool for Security (RATS), Securitycompass Web Application Analysis Tool (SWAAT), flawfinder и так далее. Но Graudit очень гибок и имеет минимальные технические требования. Тем не менее, у вас могут появиться задачи, которые Graudit решить не в состоянии. Тогда можно поискать другие варианты вот в этом списке.

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

$ git clone https://github.com/wireghoul/graudit

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

$ cd ~/bin && mkdir graudit$ ln --symbolic ~/graudit/graudit ~/bin/graudit

Добавим алиас в .bashrc (или к другому конфигурационному файлу, который вы используете):

#------ .bashrc ------alias graudit="~/bin/graudit"

Перезагружаемся:

$ source ~/.bashrc # OR$ exex $SHELL

Проверим, успешно ли прошла установка:

$ graudit -h


Если вы увидите что-то похожее, то, значит, всё хорошо.



Я буду тестировать один из уже существующих моих проектов. Перед запуском инструмента ему нужно передать базу данных, соответствующую языку, на котором написан мой проект. Базы данных находятся в папке ~/gradit/signatures:

$ graudit -d ~/gradit/signatures/js.db

Итак, я протестировал два js-файла из моего проекта, и Graudit вывел в консоль информацию об уязвимостях в моём коде:





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

Преимущества и недостатки Graudit


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

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

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

Начало...


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



На правах рекламы


Надёжный VPS и правильный выбор тарифного плана позволят меньше отвлекаться от разработки на неприятные проблемы всё будет работать без сбоев и с очень высоким uptime!

Подробнее..

Перевод Как Chrome DevTools с велосипеда на стандарт пересели

25.09.2020 14:16:06 | Автор: admin


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

Введение


Как вы, возможно, знаете, Chrome DevTools это веб-приложение HTML, CSS и JavaScript. За эти годы DevTools стала многофункциональной, умной и хорошо осведомленной о современной веб-платформе. Хотя DevTools расширился, его архитектура во многом напоминает первоначальную, когда инструмент был частью WebKit.

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

Вначале не было ничего


Сейчас у фронтенда есть множество модульных систем и их инструментов, а также стандартизированный формат модулей JavaScript. Ничего этого не было, когда начинался DevTools. Инструмент построен поверх кода WebKit, написанного более 12 лет назад.

Первое упоминание о модульной системе в DevTools относится к 2012 году: это было введение списка модулей с соответствующим списком исходников. Часть инфраструктуры Python, используемой в то время для компиляции и сборки DevTools. В 2013 года модули были извлечены в файл frontend_modules.json этим коммитом, а затем, в 2014 году, в отдельные module.json (здесь). Пример module.json:

{  "dependencies": [    "common"  ],  "scripts": [    "StylePane.js",    "ElementsPanel.js"  ]}


С 2014 года module.json используется в инструментах разработчика для указания на модули и исходные файлы. Тем временем экосистема веба быстро развивалась, и было создано множество форматов модулей: UMD, CommonJS и в конечном итоге стандартизированные модули JavaScript. Однако DevTools застрял на module.json. Не стандартизированная, уникальной модульная система имела несколько недостатков:

  1. module.json требовал собственные инструменты сборки.
  2. Не было интеграции с IDE. Конечно же, она требовала специальных инструментов для создания файлов, понятных ей: (оригинальный скрипт генерации jsconfig.json для VS Code).
  3. Функции, классы и объекты были помещены в глобальную область видимости, чтобы сделать возможным совместное использование между модулями.
  4. Был важен порядок перечисления файлов. Не было никакой гарантии, что код, на который вы полагаетесь, загружен, кроме проверки человеком.

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

Преимущества стандарта


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

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

Поскольку модули JavaScript были стандартными, это означало, что IDE, такие как VS Code, инструменты проверки типов, похожие на компилятор Closure/TypeScript, и инструменты сборки вроде Rollup и минификаторов смогут понять написанный исходный код. Более того, когда новый человек присоединяется к команде DevTools, ему не приходится тратить время на изучение проприетарного module.json.

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

Сколько стоит блеск новизны?


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

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

Последний пункт оказался очень важным. Несмотря на то, что теоретически мы могли добраться до модулей JavaScript, во время миграции мы получили бы код, который должен был бы учитывать оба типа модулей. Такое не только технически сложно, но и означает, что все инженеры, работающие над DevTools, должны знать, как работать в такой среде. Они должны были бы постоянно спрашивать себя: Что происходит в этом коде, это module.json или JS, и как я могу внести изменения?.

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


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

  1. Убедиться, что стандартные модули максимально полезны.
  2. Убедиться, что интеграция с существующими модулями на базе module.json безопасна и не приводит к негативному воздействию на пользователя (ошибки регрессии, разочарование пользователя).
  3. Давать руководства по миграции DevTools. В первую очередь с помощью встроенных в процесс сдержек и противовесов, чтобы предотвратить случайные ошибки.

Электронная таблица, преобразования и технический долг


Цель была ясна. Но ограничения module.json оказалось трудно обойти. Потребовалось несколько итераций, прототипов и архитектурных изменений, прежде чем мы разработали удобное решение. Мы закончили тем, что написали проектный документ со стратегией миграции. В этом документе указывалась первоначальная оценка времени: 2-4 недели.

Самая интенсивная часть миграции заняла 4 месяца, а от начала до конца прошло 7 месяцев!


Первоначальный план, однако, выдержал испытание временем: мы хотели научить среду выполнения DevTools загружать все файлы, старым способом использовать перечисленные в массиве scripts module.json, в то время как все файлы, перечисленные в массиве modules должны были загружаться динамическим импортом языка. Любой файл, который будет находиться в массиве modules, может работать с import и export из ES6.

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


Фрагмент таблицы миграции здесь.

Фаза экспорта


Первым этапом было добавление операторов экспорта для всех сущностей, которые должны быть разделены между модулями/файлами. Трансформация автоматизировалась с помощью запуска скрипта для каждой папки. Допустим, в module.json есть такая сущность:

Module.File1.exported = function() {  console.log('exported');  Module.File1.localFunctionInFile();};Module.File1.localFunctionInFile = function() {  console.log('Local');};


Здесь Module это имя модуля. File1 имя файла. В дереве кода это выглядит так: front_end/module/file1.JS.

Код выше преобразуется в такой:

export function exported() {  console.log('exported');  Module.File1.localFunctionInFile();}export function localFunctionInFile() {  console.log('Local');}/** Legacy export object */Module.File1 = {  exported,  localFunctionInFile,};


Первоначально мы планировали переписать импорт в один файл на этом этапе. Например, в приведенном выше примере мы бы переписали Module.File1.localFunctionInFile на localFunctionInFile. Однако мы осознали, что было бы проще автоматизировать и безопаснее разделить эти два преобразования. Таким образом, перенос всех сущностей в один файл станет второй подфазой импорта.

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

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

В конце концов, обновление самой первой папки (добавление export) заняло около недели и несколько попыток с перекладываниями.

Фаза импорта


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

Например, следующие сущности module.json:

Module.File1.exported();AnotherModule.AnotherFile.alsoExported();SameModule.AnotherFile.moduleScoped();


Преобразуются в:

import * as Module from '../module/Module.js';import * as AnotherModule from '../another_module/AnotherModule.js';import {moduleScoped} from './AnotherFile.js';Module.File1.exported();AnotherModule.AnotherFile.alsoExported();moduleScoped();


Однако при таком подходе есть оговорки:

  1. Не каждая сущность была названа по принципу Module.File.symbolName. Некоторые сущности были названы Modele.File или даже Module.CompletelyDifferentName. Несоответствие означало, что мы должны были создать внутреннее сопоставление от старого глобального объекта к новому импортированному объекту.
  2. Иногда возникали конфликты имен moduleScoped. Наиболее заметно, что мы использовали шаблон объявления определенных типов Events, там, где каждая сущность названа просто Events. Это означало, что при прослушивании нескольких типов событий, объявленных в разных файлах, в операторе import у этих Events возникнет коллизия именования.
  3. Как оказалось, между файлами существовали циклические зависимости. Это было прекрасно в контексте глобальной области видимости, так как сущность использовалась после загрузки всего кода. Однако, если вам требуется импорт, циклическая зависимость проявит себя. Такое не приводит к проблеме сразу, если только у вас нет побочных вызовов функций в коде глобальной области видимости, (они были у DevTools). В общем, потребовалось некоторое хирургическое вмешательство и рефакторинг, чтобы обезопасить трансформацию.


Дивный новый мир модулей JavaScript


В феврале 2020 года, через 6 месяцев после старта в сентябре 2019 года, были выполнены последние очистки в папке ui/. Так миграция неофициально закончилась. Когда осела пыль, мы официально отметили миграцию как законченную 5 марта 2020 года.

Теперь DevTools работают только с модулями JavaScript. Мы все еще помещаем некоторые сущности в глобальную область видимости (в файлах легаси module.js) для устаревших тестов или интеграций с другими частями инструментов разработчика архитектуры. Они будут удалены со временем, но мы не рассматриваем их как блокирующие развитие. У нас также есть руководство по стилю работы с модулями JavaScript.

Статистика


Консервативные оценки количества CL (аббревиатура changelist термин, используемый в Gerrit, аналогичное пул-реквесту GitHub), участвующих в этой миграции, составляют около 250 CL, в основном выполняемых 2 инженерами. У нас нет окончательной статистики о размере внесенных изменений, но консервативная оценка измененных строк (сумма абсолютной разницы между вставками и удалениями для каждого CL) составляет примерно 30 000 строк, то есть около 20% всего интерфейсного кода DevTools.

Первый файл с применением экспорта поддерживается в Chrome 79, выпущенном в стабильном релизе в декабре 2019 года. Последнее изменение для перехода на импорт поставляется в Chrome 83, выпущенном в стабильном релизе в мае 2020 года.

Мы знаем об одной регрессии из-за миграции в стабильном Chrome. Автозавершение фрагментов кода в меню команд сломалось из-за постороннего экспорта по умолчанию. Было и несколько других регрессий, но наши автоматизированные тестовые наборы и пользователи Chrome Canary сообщили о них. Мы исправили ошибки до того, как они могли попасть в стабильные релизы Chrome.

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

Чему мы научились?


  1. Принятые в прошлом решения могут оказать долгосрочное влияние на ваш проект. Несмотря на то, что модули JavaScript (и другие форматы модулей) были доступны в течение довольно долгого времени, DevTools не был в состоянии оправдать миграцию. Решение о том, когда мигрировать, а когда нет, трудно и держится на обоснованных догадках.
  2. Первоначальные оценки времени недели, а не месяцы. В значительной степени это связано с тем, что мы обнаружили больше неожиданных проблем, чем ожидали при первоначальном анализе затрат. Даже при том, что план миграции был основательным, технический долг блокировал работу чаще, чем нам хотелось бы.
  3. Миграция включала большое количество (казалось, не связанных между собой) очисток технического долга. Переход к современному стандартизированному формату модулей позволил нам перестроить лучшие практики кодирования на современную веб-разработку. Например, мы смогли заменить пользовательский упаковщик Python на минимальную конфигурацию Rollup.
  4. Несмотря на большое влияние на нашу кодовую базу (~20% измененного кода), было зарегистрировано очень мало регрессий. Хотя было много проблем с миграцией первых двух файлов, через некоторое время у нас был надежный, частично автоматизированный рабочий процесс. Это означало, что негативное влияние на наших стабильных пользователей было минимальным.
  5. Научить коллег тонкостям конкретной миграции трудно, а иногда и невозможно. Миграции такого масштаба трудно отслеживать и они требуют большого объема знаний в предметной области. Передача этих знаний другим людям, работающим в той же кодовой базе, сама по себе нежелательна для работы, которую они выполняют. Знание того, чем делиться, а чем не делиться необходимое искусство. Поэтому крайне важно сократить количество крупных миграций или, по крайней мере, не выполнять их одновременно.

image

Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя онлайн-курсы SkillFactory:



Подробнее..

Из песочницы Управление разработкой и производством в Asana

30.08.2020 18:21:45 | Автор: admin
Всем привет, меня зовут Константин Кузнецов, я генеральный директор и основатель компании RocketSales. В IT-сфере довольно часто встречается история, когда отдел разработки живет в своей вселенной. В этой вселенной есть увлажнители воздуха на каждом рабочем столе, куча гаджетов и клинеров для мониторов и клавиатур и, скорее всего, своя система управления задачами и проектами.

Что в этом такого?


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

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

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

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

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

Немного о знакомстве с Asana


На поиск удобного софта для проектного управления я потратил 10 лет. Trello, Jira, Планфикс, Мегаплан, Битрикс24 и десятки других таск-трекеров не прошли тест на прочность. Потом я нашел Asana. И все сложилось.

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



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

Коротко опишу процесс от продажи до реализации проекта


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

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

Благодаря связке amoCRM + Asana, при передаче сделки из отдела продаж в производство и обратно, работа нигде не прерывается. Голубым цветом обозначена зона ответственности отдела продаж, оранжевым отдела производства, розовым отдела разработки.



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

Итак, когда руководитель принял проект в производство, менеджер по продажам в 1 клик переходит в Asana (скриншот). Из amoCRM проект автоматически создаётся в Asana.



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



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

  1. Найти/Создать проект Клиента + Прикрепить туда задачу
  2. Заполнить задачу информацией по сделке
  3. Создать сделку из текущей задачи



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

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

Как мы группируем задачи и проекты клиентов


Из общей доски всех проектов менеджер добавляет проект еще на 3 доски:

  1. персональная доска клиента;
  2. портфель активных клиентов;
  3. портфель менеджера.

Разберемся, для чего нам каждая из сущностей.

На скриншоте вы видите персональную доску клиента.



Зачем эта доска?

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

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

Что есть на этой доске?

Наша Asana связана с несколькими сервисами:

  • CRM-система (для взаимодействия с отделом продаж),
  • TimeDoctor (для учета времени),
  • ERP-система (для агрегации всех данных в едином интерфейсе).

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



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

Что дает использование доски?

В итоге в ERP-системе мы видим Отчет по проектам. Статус сделки, участники проекта, бюджет на проект, количество отработанных часов и сроки.



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

Портфели Asana


Эта функциональность реализована в Asana уже давно. Но мы не сразу ее оценили. Сперва мы просто собрали в портфели все проекты наших менеджеров. Оказалось, что за время работы в компании Денис Киселев поработал с 61 клиентом.

Знать это прикольно, но недостаточно, чтобы оправдывать потраченное на сбор время. И мы забили на портфели. Все поменялось, когда мы приравняли проект в Asana к одной сделке в CRM-системе.

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

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

Портфель проектного отдела


На скриншоте вы видите отсортированные по сотрудникам проекты.



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

Руководитель быстро может оценить:

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

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

Портфель сотрудника


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

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



Решение багов и кастомная разработка


Отдельная команда отвечает у нас за разработку. К ней в рамках бизнес-процесса поступают задачи двух типов:

  1. баг,
  2. новая разработка.

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

Процесс разработки, в целом, выглядит так.



Задачи падают на доску разработки в Asana. Вот она.



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



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

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

  • на личной доске проектного менеджера,
  • на доске техподдержки,
  • на доске разработки.

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

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


Во-первых, клиентские проекты стали более долгосрочными. За счет постоянно пополняемого бэклога вырос средний чек.

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

В-третьих, и сотрудники, и руководители, и клиенты получили полную прозрачность в запланированных и выполненных задачах. Мы научились УПРАВЛЯТЬ проектами, осознали, что это абсолютно технический процесс, из которого можно почти полностью исключить человеческий фактор.

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

Сейчас, видя процесс разработки и технической настройки систем:

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

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

Больше не тимлид как не потерять себя и найти снова

28.08.2020 12:23:00 | Автор: admin
Вернёмся года на два назад, когда я был разработчиком. Что я думал? Хочу стать тимлидом. Это круто, он решает все вопросы, получает больше денег, им становятся после сеньора. Тогда не было никого, кто сказал бы мне: это вообще про другое. Пришлось учиться на своих ошибках.



Я дважды становился тимлидом


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

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



А еще делали все сами как умели. Помню, как ставил Ubuntu на рэковый сервер, который отдал нам один из инвесторов. Когда я включал его, он издавал звук взлетающего вертолета!

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

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


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


Особенно запомнилась Scrum и XP: заметки с передовой от Хенрика Книберга. Процесс в D был выстроен близко к этой методологии: в результате весь менеджмент и продавцы отлично понимали, когда будет результат.

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

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

Так Петя меня раскусил и узнал про опыт руководства командой в T и заочном обучении скраму в D.


В какой-то момент он предложил мне провести стендап.


Операция преемник в моем случае выглядела вот так и заняла 6 минут)

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

Все происходит само собой, будто в сторону тимлидства тебя толкает невидимый Закон Притяжения.


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

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

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

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

Вот как выглядел примерный круг обязанностей тимлида в Skyeng на момент начала истории:



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

Что поменялось и как я с этим боролся


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

Однако со временем чувство эйфории прошло, наступили будни. Вот что я заметил за собой.

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


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

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

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

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



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


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

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

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


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

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

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

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

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

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

Больше не тимлид: как не потерять себя и найти снова


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

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

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



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

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

Так пришла идея обсудить его в публичном формате с:

  • Егором Толстым (подкаст и курсы Podlodka) он сделал выбор в пользу управления продуктом и расскажет о моменте, когда понял, что устал от руководства разработкой,
  • Вадимом Мартыновым (Контур и сообщество RndTech) он вернулся в разработчики и расскажет, как переучивался писать код и как все это сказалось на финансах,
  • и Евгением Котом (Wrike и тот самый доклад о болях тимлида) в качестве ведущего.

Все пройдет онлайн в ближайшую среду (2 сентября) в 19 часов по Москве/Киеву/Минску на ютубе: для зрителей будет чат и простая возможность включиться голосом. А если у вас останутся силы пообщаемся в зуме.


Здесь можно поставить напоминалку в календарь.

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

Зачем нам вулканец на борту обзор Spock Framework

28.08.2020 16:14:16 | Автор: admin
Автоматизация тестирования помогает постоянно контролировать качество IT-продукта, а также снижать затраты в долгосрочной перспективе. В автоматизации существуют различные подходы, например, Behavior Driven Development (BDD), разработка через поведение.

С этим подходом связаны инструменты cucumber, robot framework, behave и другие, в которых разделены сценарии выполнения и реализация каждой конструкции. Такое разделение помогает составить удобочитаемые сценарии, но требует значительных затрат времени и поэтому может быть непрактичным при написании реализации.

Рассмотрим, как можно упростить работу с BDD, используя подходящие инструменты например, фреймворк Spock, который сочетает в себе красоту, удобство принципов BDD и особенности jUnit.



Spock framework


Spock фреймворк для тестирования и спецификации приложений на языках Java и Groovy. Благодаря использованию в качестве основы платформы JUnit этот фреймворк совместим со всеми популярными IDE (в частности, IntelliJ IDEA), различными инструментами сборки (Ant, Gradle, Maven) и continuous integration (CI) серверами.

Как пишут разработчики фреймворка, Spock вдохновлен JUnit, RSpec, jMock, Mockito, Groovy, Scala, вулканцами и другими увлекательными формами жизни.

В этой статье мы рассмотрим последнюю доступную версию, Spock Framework 2.0. Ее особенности: возможность использования JUnit5, Java 8+, groovy 2.5 (также существует сборка с версией 3.0). Spock распространяется по лицензии Apache 2.0 и имеет отзывчивое сообщество пользователей. Разработчики фреймворка продолжают дорабатывать и развивать Spock, который уже включает в себя множество расширений, позволяющих тщательно настроить запуск тестов. Например, одно из наиболее интересных анонсированных направлений доработки это добавление параллельного исполнения тестов.

Groovy


Groovy является объектно-ориентированным языком программирования, разработанным для платформы Java как дополнение с возможностями Python, Ruby и Smalltalk. Groovy использует Java-подобный синтаксис с динамической компиляцией в JVM байт-код и напрямую работает с другим Java-кодом и библиотеками. Язык может использоваться в любом Java-проекте или как скриптовый язык.

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

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

Особенности Spock Framework


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

Спецификация представляет собой класс groovy, расширяющий spock.lang.Specification

class MyFirstSpecification extends Specification {  // fields  // fixture methods  // feature methods  // helper methods}

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

С помощью аннотации @Shared можно дать доступ к полю классам-наследникам спецификации.

abstract class PagesBaseSpec extends Specification {    @Shared    protected WebDriver driver    def setup() {        this.driver = DriverFactory.createDriver()        driver.get("www.anywebservice.ru")    }    void cleanup() {        driver.quit()    }}


Методы настройки класса спецификации:

def setupSpec() {} // запускается при работе первого feature метода из спецификации def setup() {}     // запускается перед каждым feature методомdef cleanup() {}   // запускается после каждого feature методаdef cleanupSpec() {} // запускается после работы последнего feature метода из спецификации

В следующей таблице рассмотрим, у каких ключевых слов и методов Spock framework есть аналоги в JUnit.



Блоки теста


В Spock Framework каждая фаза теста выделена в отдельный блок кода (см. пример в документации).



Блок кода начинается с лейбла и завершается началом следующего блока кода или окончанием теста.

Блок given отвечает за настройку начальных условий теста.

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

В тех случаях, когда есть возможность сократить конструкцию when-then до одного выражения, можно использовать один блок expect. Далее будут использованы примеры из официальной документации Spock framework:

when:def x = Math.max(1, 2) then:x == 2

или одно выражение

expect:Math.max(1, 2) == 2

Блок cleanup применяют для освобождения ресурсов перед следующей итерацией теста.

given:def file = new File("/some/path")file.createNewFile() // ... cleanup:file.delete()

Блок where применяют для передачи данных для тестирования (Data Driven Testing).

def "computing the maximum of two numbers"() {  expect:  Math.max(a, b) == c   where:  a << [5, 3]  b << [1, 9]  c << [5, 9]}

Виды передачи входных данных будут рассмотрены далее.

Пример реализации теста на Spock Framework


Далее рассмотрим подходы к реализации тестирования веб-страницы авторизации пользователя в системе с использованием selenium.

import helpers.DriverFactoryimport org.openqa.selenium.WebDriverimport spock.lang.Sharedimport spock.lang.Specificationabstract class PagesBaseSpec extends Specification {    @Shared    protected WebDriver driver        def setup() {        this.driver = DriverFactory.createDriver()        driver.get("www.anywebservice.ru")    }    void cleanup() {        driver.quit()    }}

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

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

import pages.LoginPageimport spock.lang.Issueclass LoginPageTest extends PagesBaseSpec {    @Issue("QAA-1")    def "QAA-1: Authorization with correct login and password"() {        given: "Login page"        def loginPage = new LoginPage(driver)        and: "Correct login and password"        def adminLogin = "adminLogin"        def adminPassword = "adminPassword"        when: "Log in with correct login and password"        loginPage.login(adminLogin, adminPassword)        then: "Authorized and moved to main page"        driver.currentUrl == "www.anywebservice.ru/main"    }}

Спецификация страницы авторизации наследуется от базовой спецификации страниц. Аннотация Issue задает идентификатор теста во внешней системе трекинга (например, Jira). В следующей строке мы видим название теста, которое по соглашению задается строковыми литералами, что позволяет использовать любые символы в названии теста (в том числе и русскоязычные). В блоке given происходит инициализация page object класса страницы авторизации, а также получение корректных логина и пароля для авторизации в системе. В блоке when выполняется действие по авторизации. В блоке then проверка ожидаемого действия, а именно успешная авторизация и переадресация на главную страницу системы.

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

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

Data Driven Testing в Spock Framework


Data Driven Testing = table-driven testing = parameterized testing

Для тестирования сценария с несколькими параметрами можно использовать различные варианты их передачи.

Таблицы данных (Data Tables)


Рассмотрим несколько примеров из официальной документации фреймворка.

class MathSpec extends Specification {  def "maximum of two numbers"() {    expect:    Math.max(a, b) == c     where:    a | b | c    1 | 3 | 3    7 | 4 | 7    0 | 0 | 0  }}

Каждая строка в таблице отдельная итерация теста. Также таблица может быть представлена и одним столбцом.

where:a | _1 | _7 | _0 | _

_ объект-заглушка класса спецификации.

Для лучшего визуального восприятия параметров можно переписать пример выше в следующем виде:

def "maximum of two numbers"() {    expect:    Math.max(a, b) == c     where:    a | b || c    1 | 3 || 3    7 | 4 || 7    0 | 0 || 0}
Теперь мы видим, что a, b входные параметры, а c ожидаемое значение.

Потоки данных (Data pipes)


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

...where:a << [1, 7, 0]b << [3, 4, 0]c << [3, 7, 0]

Здесь левый сдвиг << перегруженный groovy оператор, который теперь выполняет роль добавления элементов в список.

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

1 итерация: a=1, b=3, c=3;
2 итерация: a=7, b=4, c=7;
3 итерация: a=0, b=0, c=0.

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

@Shared sql = Sql.newInstance("jdbc:h2:mem:", "org.h2.Driver") def "maximum of two numbers"() {  expect:  Math.max(a, b) == c   where:  [a, b, c] << sql.rows("select a, b, c from maxdata")}


Переменная как данные (Data Variable Assignment)


...where:a = 3b = Math.random() * 100c = a > b ? a : b

Здесь мы видим динамически вычисляемую переменную c в тестовых данных.

Комбинация различных видов передачи параметров


...where:a | _3 | _7 | _0 | _ b << [5, 0, 0] c = a > b ? a : b

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

Пример реализации параметризованного теста на Spock Framework


@Issue("QAA-1-parametrized")def "QAA-1-parametrized: Authorization with correct login and password"() {   given: "Login page"   def loginPage = new LoginPage(driver)   when: "Log in with correct login and password"   loginPage.login(login, password)   then: "Authorized and moved to main page"   driver.currentUrl =="www.anywebservice.ru/main"   where: "Check for different logins and passwords"   login            | password   "adminLogin"     | "adminPassword"   "moderatorLogin" | "moderatorPassword"   "userLogin"      | "userPassword"}

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

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

Пример реализации параметризованного теста с доработанной спецификацией


До доработки


abstract class PagesBaseSpec extends Specification {    @Shared    protected WebDriver driver    def setup() {        this.driver = DriverFactory.createDriver()        driver.get("www.anywebservice.ru")    }    void cleanup() {        driver.quit()    }}


После доработки


import helpers.DriverFactoryimport org.openqa.selenium.WebDriverimport spock.lang.Sharedimport spock.lang.Specificationabstract class PagesNoRestartBaseSpec extends Specification {    @Shared    protected WebDriver driver    def setupSpec() {        this.driver = DriverFactory.createDriver()    }    def setup() {        this.driver.get("www.anywebservice.ru")    }    def cleanup() {        this.driver.get("www.anywebservice.ru/logout")        this.driver.manage().deleteAllCookies();    }    void cleanupSpec() {        this.driver.quit()    }}

В обновленной спецификации мы видим, что процедура создания веб-драйвера будет выполняться только при настройке класса спецификации, а закрытие браузера только после завершения работы тестов из спецификации. В методе setup() мы видим тот же код получения веб-адреса сервиса и его открытие в браузере, а в методе cleanup() переход по адресу www.anywebservice.ru/logout для завершения работы с сервисом у текущего пользователя и удаления файлов куки (для тестирования текущего веб-сервиса данной процедуры достаточно, чтобы имитировать уникальный запуск). Код самого теста не изменился.

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

Сравнение тестов на testNG, pytest, pytest-bdd


Для начала мы рассмотрим реализацию теста на тестовом фреймворке testNG на языке программирования Java, который также, как и Spock Framework, вдохновлен фреймворком jUnit и поддерживает data-driven testing.

package javaTests;import org.testng.Assert;import org.testng.annotations.*;import pages.LoginPage;public class LoginPageTest extends BaseTest {    @BeforeClass    public final void setup() {        createDriver();        driver.get("www.anywebservice.ru");    }    @DataProvider(name = "userParameters")    public final Object[][] getUserData(){        return new Object[][] {                {"adminLogin", "adminPassword"},                {"moderatorLogin", "moderatorPassword"},                {"userLogin", "userPassword"}        };    }    @Test(description = "QAA-1-1: Authorization with correct login and password",            dataProvider = "userParameters")    public final void authorizationWithCorrectLoginAndPassword(String login, String password){        //Login page        LoginPage loginPage = new LoginPage(driver);        //Log in with correct login and password        loginPage.login(login, password);        //Authorized and moved to main page        Assert.assertEquals("www.anywebservice.ru/main", driver.getCurrentUrl());    }    @AfterMethod    public final void cleanup() {        driver.get("www.anywebservice.ru/logout");        driver.manage().deleteAllCookies();    }    @AfterClass    public final void tearDown() {        driver.quit();    }}

Здесь мы можем видеть тестовый класс со всеми необходимыми setup(), cleanup() методами, а также параметризацию теста в виде дополнительного метода getUserData() с аннотацией @DataProvider, что выглядит несколько громоздко, после того, что мы рассмотрели в тесте с использованием Spock Framework. Также для понимания того, что происходит в тесте, были оставлены комментарии, аналогичные описанию шагов.

Стоит отметить, что в testNG, в отличие от Spock Framework, реализована поддержка параллельного выполнения теста.



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

import pytestfrom selenium.webdriver.support import expected_conditionsfrom selenium.webdriver.support.wait import WebDriverWaitfrom PageObjects.LoginPage import LoginPageclass TestLogin(object):    @pytest.mark.parametrize("login,password", [        pytest.param(("adminLogin", "adminPassword"), id='admin'),        pytest.param(("moderatorLogin", "moderatorPassword"), id='moderator'),        pytest.param(("userLogin", "userPassword"), id='user')    ])    def test_authorization_with_correct_login_and_password(self, login, password, driver, test_cleanup):        # Login page        login_page = LoginPage(driver)        # Log in with correct login and password        login_page.login(login, password)        # Authorized and moved to main page        assert expected_conditions.url_to_be("www.anywebservice.ru/main")     @pytest.fixture()    def test_cleanup(self, driver):        yield "test"        driver.get("www.anywebservice.ru/logout")        driver.delete_all_cookies()

Здесь мы также видим поддержку data-driven testing в виде отдельной конструкции, схожей с @DataProvider в testNG. Метод настройки веб-драйвера спрятан в фикстуре driver. Благодаря динамической типизации и фикстурам pytest, код этого теста выглядит чище, чем на Java.



Далее перейдем к обзору кода теста с использованием плагина pytest-bdd, который позволяет писать тесты в виде feature файлов Gherkin (чистый BDD-подход).

login.feature

Feature: Login page  A authorization  Scenario: Authorizations with different users    Given Login page    When Log in with correct login and password    Then Authorized and moved to main page


test_login.py

import pytestfrom pytest_bdd import scenario, given, when, thenfrom selenium.webdriver.support import expected_conditionsfrom selenium.webdriver.support.wait import WebDriverWaitfrom PageObjects.LoginPage import LoginPage@pytest.mark.parametrize("login,password", [    pytest.param(("adminLogin", "adminPassword"), id='admin'),    pytest.param(("moderatorLogin", "moderatorPassword"), id='moderator'),    pytest.param(("userLogin", "userPassword"), id='user')])@scenario('login.feature', 'Authorizations with different users')def test_login(login, password):    pass@given('Login page')def login_page(driver):    return LoginPage(driver)@when('Log in with correct login and password')def login_with_correct_login_and_password(login_page, login, password):    login_page_object = login_page    login_page_object.login(login, password)@then('Authorized and moved to main page')def authorized_and_moved_to_main_page(driver, login):    assert expected_conditions.url_to_be("www.anywebservice.ru/main")

Из плюсов можно выделить то, что это все еще фреймворк pytest, который имеет множество плагинов для различных ситуаций, в том числе и для параллельного запуска тестов. Из минусов сам чистый BDD-подход, который будет постоянно ограничивать разработчика своими особенностями. Spock Framework дает возможность писать более лаконичный и простой в оформлении код, по сравнению со связкой PyTest + pytest-bdd.



Заключение


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

Плюсы:

  • Использование принципов BDD вместо чистого BDD-подхода дает большую гибкость при написании тестов.
  • Написанная тестовая спецификация является также и документацией системы.
  • Наличие различных расширений для настройки тестов.
  • Язык groovy (динамическая типизация, синтаксический сахар, closures или замыкания).


Минусы:

  • Динамическая типизация языка groovy. Поскольку применяется динамическая типизация, то механизмы предугадывания, используемые в IDE для анализа содержимого переменной, при долгой работе могут начать сбоить. Если рассматривать Intellij IDEA, то постоянно ведутся доработки в этом направлении, что, несомненно, радует.
  • Динамическая компиляция groovy кода в JVM байт-код. Если кратко, то не стоит писать все подряд на groovy, поскольку вы можете существенно проиграть во времени компиляции данного кода, особенно если он занимает много строк кода и часто используется. Важные части своего тестового фреймворка все же стоит писать на java, а groovy оставить для тестов.
  • Набор расширений не такой обширный, как у testNG, к примеру. Как следствие отсутствие параллельного запуска тестов. Есть планы добавить эту функциональность, но сроки их реализации неизвестны.

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

Что еще можно почитать:
Подробнее..

Как программист читает Происхождение видов Дарвина

01.09.2020 08:13:07 | Автор: admin
Во время чтения Происхождения видов путем естественного отбора Чарльза Дарвина, меня не покидало стойкое дежавю. Позже я понял, что механизмы, описанные в книге сильно коррелируют с механизмами enterprise разработки в больших компаниях. Где в качестве условий окружающей среды выступают постоянно меняющиеся бизнес-требования и программисты, а в качестве организмов код.

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

Глава V. Законы вариации. Краткий обзор


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

Части гомологичные склонны варьировать одинаковым образом, а равно и связываться друг с другом. Модификация частей внешнего интерфейса действует на части внутренней структуры. Когда одна какая-нибудь часть сильно развивается, она, возможно, отвлекает ресурсы разработки от с нею смежных частей, и всякая часть структуры приложения, которая может быть устранена без ущерба, будет устранена. Изменения в строении в раннем возрасте могут воздействовать на части, развивающиеся позднее; несомненно, встречаются многочисленные случаи коррелятивной вариации, природу которой мы не способны понять. Части, многократно повторяющиеся, изменчивы как в своем числе, так и в строении, и это, вероятно, проистекает из отсутствия строгой специализации таких частей для какой-либо особой функции, так что их модификациям не препятствовал естественный отбор. Последствием этой же причины, быть может, является факт, что программные продукты, стоящие на низших ступенях зрелости программного продукта, более изменчивы, чем вышестоящие, вся структура приложения которых более специализирована. Функции рудиментарные, будучи бесполезными, не подпадают под действие естественного отбора и поэтому изменчивы. Признаки компонентов, т.е. признаки, которыми компоненты одной библиотеки стали различаться с того времени, как они ответвились от общего предка, более изменчивы, чем признаки библиотечные, т. е. такие, которые унаследованы издавна и у которых на протяжении указанного периода не возникали различия. В этих замечаниях мы касались специальных функций или частей, но тем не менее изменчивых, потому что они варьировали еще недавно и вследствие этого становились различными; но во II главе мы видели, что тот же принцип применим и к проекту в целом. Мы убедились, что в области, заключающей много компонентов данной библиотеки, т. е. где недавно происходило значительное изменение и дифференцировка или где активно шло производство новых форм компонентов, в такой области и у таких компонентов мы и в настоящее время встречаем в среднем наибольшее число разновидностей. Сигнатуры функций очень изменчивы; они же сильно различаются у компонентов одной группы. Изменчивость одних и тех же частей структуры приложения обычно была полезной как для образования сигнатур функций между двумя протоколами взаимодействия одного компонента, так и образования компонентных различий между компонентами одной библиотеки. Всякая часть или функция, чрезмерно или исключительным образом развитые по сравнению с той же частью или функцией у родственных компонентов, должны были подвергнуться модификации в необычайных размерах со времени возникновения этой библиотеки; отсюда нам понятно, почему они еще часто изменчивы в гораздо более значительной мере, чем другие части, так как вариация представляет медленный и долго длящийся процесс и естественный отбор в подобных случаях не располагал до сих пор достаточным временем, чтобы осилить тенденцию к дальнейшей изменчивости и реверсии к менее модифицированному состоянию. Но когда компонент с необычайно развитой функцией сделался родоначальником многочисленных модифицированных потомков, что, согласно моему взгляду, должно быть крайне медленным процессом, требующим огромного промежутка времени, то в подобном случае естественный отбор уже успел сообщить этой функции постоянные черты, несмотря на необычайность её развития. Компоненты, унаследовавшие от своего общего предка почти одинаковую конституцию и подвергшиеся воздействию сходных условий, естественно, имеют наклонность давать аналогичные вариации или иногда возвращаются к некоторым признакам своих далеких предков. Хотя, из-за реверсии и аналогичной вариации, новые и важные модификации не могут возникать, такие модификации будут добавляться к прекрасному и гармоничному многообразию разработки.
Какова бы ни была причина, быть может, каждого слабого различия между версиями библиотеки и причина для каждого из них должна существовать, мы имеем основание полагать, что неуклонное кумулирование благоприятных различий вызвало все наиболее важные модификации строения в связи с жизненным циклом каждого компонента.

Термины, которые я заменил в оригинальном параграфе



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


Еще заменил термины, которые в данном контексте будут выглядеть странно:
  • употребление -> использование (так как слово выглядит немного устаревшим)
  • организация -> структура приложения (чтобы смысл был верным)
  • образ жизни -> жизненный цикл


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

Читать оригинальный параграф из книги
Наше незнание законов вариации глубоко. Ни в одном из 100 случаев мы не можем определить причину, почему тот или другой орган изменился. Но во всех случаях, где мы обладаем средствами для сравнения, оказывается, что образование меньших различий между разновидностями одного вида вызывается действием тех же законов, что и больших различий между видами одного рода. Перемены в условиях обычно вызывают только колеблющуюся вариабельность, но иногда ведут к прямым и определенным результатам: и эти результаты с течением времени могут сделаться более сильно выраженными, хотя в пользу этого еще не имеется достаточного доказательства. Привычка в образовании конституциональных особенностей, употребление в усилении органа и неупотребление в их ослаблении и уменьшении во многих случаях кажутся мощными в своем действии. Части гомологичные склонны варьировать одинаковым образом, а равно и связываться друг с другом. Модификация твердых и наружных частей действует на части мягкие и внутренние. Когда одна какая-нибудь часть сильно развивается, она, возможно, отвлекает питательные вещества от с нею смежных частей, и всякая часть организации, которая может быть устранена без ущерба, будет устранена. Изменения в строении в раннем возрасте могут воздействовать на части, развивающиеся позднее; несомненно, встречаются многочисленные случаи коррелятивной вариации, природу которой мы не способны понять. Части, многократно повторяющиеся, изменчивы как в своем числе, так и в строении, и это, вероятно, проистекает из отсутствия строгой специализации таких частей для какой-либо особой функции, так что их модификациям не препятствовал естественный отбор. Последствием этой же причины, быть может, является факт, что органические существа, стоящие на низших ступенях органической лестницы, более изменчивы, чем вышестоящие, вся организация которых более специализирована. Органы рудиментарные, будучи бесполезными, не подпадают под действие естественного отбора и поэтому изменчивы. Признаки видовые, т. е. признаки, которыми виды одного рода стали различаться с того времени, как они ответвились от общего предка, более изменчивы, чем признаки родовые, т. е. такие, которые унаследованы издавна и у которых на протяжении указанного периода не возникали различия. В этих замечаниях мы касались специальных органов или частей, но тем не менее изменчивых, потому что они варьировали еще недавно и вследствие этого становились различными; но во II главе мы видели, что тот же принцип применим и к особи в целом. Мы убедились, что в области, заключающей много видов данного рода, т. е. где недавно происходило значительное изменение и дифференцировка или где активно шло производство новых видовых форм, в такой области и у таких видов мы и в настоящее время встречаем в среднем наибольшее число разновидностей. Вторичные половые признаки очень изменчивы; они же сильно различаются у видов одной группы. Изменчивость одних и тех же частей организации обычно была полезной как для образования вторичных половых различий между двумя полами одного вида, так и образования видовых различий между видами одного рода. Всякая часть или орган, чрезмерно или исключительным образом развитые по сравнению с той же частью или органом у родственных видов, должны были подвергнуться модификации в необычайных размерах со времени возникновения этого рода; отсюда нам понятно, почему они еще часто изменчивы в гораздо более значительной мере, чем другие части, так как вариация представляет медленный и долго длящийся процесс и естественный отбор в подобных случаях не располагал до сих пор достаточным временем, чтобы осилить тенденцию к дальнейшей изменчивости и реверсии к менее модифицированному состоянию. Но когда вид с необычайно развитым органом сделался родоначальником многочисленных модифицированных потомков, что, согласно моему взгляду, должно быть крайне медленным процессом, требующим огромного промежутка времени, то в подобном случае естественный отбор уже успел сообщить этому органу постоянные черты, несмотря на необычайность его развития. Виды, унаследовавшие от своего общего предка почти одинаковую конституцию и подвергшиеся воздействию сходных условий, естественно, имеют наклонность давать аналогичные вариации или иногда возвращаются к некоторым признакам своих далеких предков. Хотя, из-за реверсии и аналогичной вариации, новые и важные модификации не могут возникать, такие модификации будут добавляться к прекрасному и гармоничному многообразию природы.
Какова бы ни была причина, быть может, каждого слабого различия между потомством и их родителями и причина для каждого из них должна существовать, мы имеем основание полагать, что неуклонное кумулирование благоприятных различий вызвало все наиболее важные модификации строения в связи с образом жизни каждого вида.




Небольшое объяснение



После полной замены, я обратил внимание, что читать текст очень сложно (кто бы мог подумать?). Этому много причин. Одной из самых главных является выбранный параграф. Дело в том, что этот параграф включает в себя краткий пересказ всего, что было описано в самой главе, поэтому текст очень ёмкий и сжатый. К сожалению, мне не удалось найти другой подходящий параграф, в котором можно было бы такими минимальными телодвижениями провести замену терминов.

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

Пример 1


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

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


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

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

Пример 2


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

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

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

Пример из жизни:
Если вы используете в проекте, например, кнопки из CSS Bootstrap фреймворка, то очевидно, что чаще будет меняться содержимое классов .btn или .btn-primary, чем переименовывание этих классов во что-нибудь в духе .g-button или g-button-first

Заключение


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

P.S.: Большое спасибо моим друзьям и коллегам. Они не подозревали, для чего подсказывают мне термины.
Подробнее..

Как начать подгорать, но не выгореть в проекте, где было срочно нужно

16.09.2020 10:17:24 | Автор: admin
4 с лишним года назад я писал код в стартапе, который хотел наносить пользу клиентам частных медицинских клиник. Режим стартапа предполагал стабильное ощущение дедлайна, жесткую фокусировку и частую смену планов на лету. И я выгорел. На любимой тогда работе.



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

Чтобы выгорание началось, нужно повторить простой цикл несколько раз


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

Мы делаем ВОТ ЭТО за неделю!

Это невозможно.

В следующий понедельник нужно в проде.

Ок, давай посмотрим, что можно сделать.

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

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


Разработка напоминала короткие контракты. Параллельно менялось законодательство. Мы не могли позволить себе прогнозировать слишком далеко.

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

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


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

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

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

Я стал заморачиваться, что не приношу результат. И снова стал искать себя.


История о том, как фигачить, но не выгорать дотла


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

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

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

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

Было принято решение о срочной миграции нашего проекта в другой и так я снова вписался в горячку стартапа.


Давайте расскажу, как и для чего мы работали:

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


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

  • Первые недели работали по 12 часов в день. Потом постепенно уменьшали до восьми. В первые недели что-то делали и по субботам. Затем вернулись к пятидневке и ввели субботник: просто какой-то день на рабочей неделе, когда мы удаляли код, рефакторили и так далее.
  • Каждый день это спринт с планированием и демо. Каждое утро мы обсуждали новые фичи, днем понимали, какая часть задач дойдёт до прода. Вечером на демо разработка показывала их. У нас был запрет на деплой с 9 до 15 часов, когда на сайт приходила основная масса педагогов и детей, поэтому иногда делали только ядро задачи, а иногда засиживались: кажется, когда мы только запускали лидерборды, сидели до полуночи, чтобы завтра всё работало.



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

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

Мне трудно с чем-то сравнить выгорание, но, наверное, так бывает у спортсменов: когда долго идешь к цели, после наступает опустошение.

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


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

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


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


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

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

Цели могут быть амбициозными и меняться в большую сторону, но разбейте их достижение на этапы и просчитайте заранее. В нашем случае, каждая из целей каким-то образом была просчитана аналитиками с точностью практически до даты. А затем разложена по градации: не просто получить 10М выполненных заданий на платформе через 6 недель, а сделать 100К через неделю, сделать 1М через две.

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



Наш дизайнер завел открытый Slack-канал, куда каждый день писал свое настроение в %. Ради интереса, я вывел корреляцию. Вот она:


30 мая день, когда мы закончили проект.

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

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


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


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

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

В итоге мы получали куда более управляемый набор задач. Чаще видели прогресс. И при необходимости параллелили работу. Даже демо на проде давало мотивацию делать фичи, скрываемые за конфигом. А еще очень быстро фиксить то, что ломалось) Результаты придавали сил: в режиме сжатых сроков очень важно наблюдать их как можно чаще, визуализировать их.


Но главное, что я понял: челленджи деструктивны на долгой дистанции


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

Но вашей общей задачей будет выйти из этого режима быстро.

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

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

ERP-система управление показателями на стыке коммерции и IT

09.09.2020 14:04:11 | Автор: admin

Вообще заголовок у этой статьи должен быть сильно длиннее.

ERP-система RocketSales: управление показателями на стыке коммерции и IT.
С интеграцией с amoCRM и платформой для управления проектами Asana.
С тайм-трекингом и KPI, основанной на человекочасах.
С полной и чертовски сквозной автоматизацией.
В условиях пандемии и вынужденной удаленки.

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

Короткая история, которая даст мотивацию читать до конца

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

Собрали рабочую группу, оценили объем работ нашей команды в 200 часов. При условии, что над проектом с высоким приоритетом работает 4-5 человек - это 1, ладно, 2 месяца до полностью готовой системы.

Начали делать.

В итоге, проект растянулся на год. Я негодовал, почему так неэффективно, топ-менеджмент недоумевал, почему так долго, менеджер проекта выбился из сил, потому что не ожидал, что будет так сложно.

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

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

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

В итоге, разработка собственной ERP-системы обошлась нам в 2 490 часов. Это больше, чем в 10 раз превысило наши ожидания. Средняя ставка часа среди компаний, которые разрабатывают такие решения на заказ, составляет 3 000 рублей. Если оценивать подобный проект по рыночной цене, выходит около 7,5 млн. рублей.

На скриншоте - карточка проекта по разработке ERP в нашей же ERP. Здесь видно, сколько всего часов потратили сотрудники, кто участвовал в проекте.

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

Зачем мы вообще затеяли разработку собственной системы учета ресурсов?

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

В ERP ты видишь: 2 490 часов - огромный объем задач. Абсолютная прозрачность по сложности проекта и эффективности каждого в команде. Вот бэклог из карточки проекта в Asana (платформы для управления проектами).

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

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

Спрашиваешь у подрядчика: А сколько денег нужно?

Он говорит: А мы не знаем, будет зависеть от количества часов.

Даешь 500 тысяч, они заканчиваются.Подрядчик просит еще.

Спрашиваешь: А сколько еще нужно?

Он отвечает: А мы не знаем, будет зависеть от количества часов.

И ты даешь еще 500 тысяч, и они снова заканчиваются, в отличие от проектной работы.

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

Что за зверь, эта ERP-система?

ERP - от англ. Enterprise Resource Planning, планирование ресурсов предприятия. Это концентрат огромного объема информации. Главная цель внедрения ERP в компанию - отслеживание постоянно обновляемых показателей, позволяющих оценить текущие затраты ресурсов по отношению к маржинальности и другим параметрам успешности деятельности команды.

В RocketSales ERP собирает данные из трех систем:

  1. amoCRM, в которой мы ведем продажи и некоторые этапы производства,

  2. Asana, в которой мы ведем проекты и задачи компании,

  3. TimeDoctor, в котором мы фиксируем время работы каждого сотрудника.

Расскажу чуть подробнее про организацию процесса в каждом из инструментов.

amoCRM

Мы не только внедряем amoCRM клиентам, но активно используем ее сами. И с улыбкой смотрим на конкурентов, которые внедряют клиентам Битрикс24, а сами ведут продажи в amoCRM.

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

  • бюджет,

  • дата передачи в производство,

  • расчетный фонд времени на реализацию проекта.

Примечание. Как мы считаем время, которое понадобится на реализацию задачи.

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

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

Менеджер проекта тоже работает в CRM-системе. При приеме в производство он заполняет кастомные поля:

  • дата приема и сдачи работ,

  • важные примечания.

При переносе сделки на этап Принят в производство в ERP автоматически создается новый проект. Из amoCRM, при помощи разработанного нами виджета, в 1 клик проектный менеджер создает одноименный проект в платформе Asana. Посмотрим, какие данные наша ERP вытаскивает из Asana.

Asana

Про это я подробно рассказывал в предыдущей статье. Мы фанаты Asana, их первые сертифицированные партнеры в России. Мы внедряем ее клиентам, консультируем команды по 200-300 сотрудников и даже запустили свой обучающий курс по самостоятельному внедрению Asana в процессы команды.

Вкратце: из amoCRM мы "прокидываем" проект в Asana. В Asana происходит вся коммуникация по задачам клиента. Туда мы вносим новые задачи, если есть необходимость в доработке. Там фиксируем промежуточные статусы.

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

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

Time Doctor

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

Видно время, отработанное сегодня. Понятно, над какими задачами, когда и сколько ты работал.

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

Система мотивации исполнителей состоит из 3 частей:

  • фиксированный оклад,

  • премиальная ставка часа.

  • премия за соблюдение стандартов качества,

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

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

Сквозная интеграция обеспечивается расширением для Google Chrome, которое позволяет видеть текущую стоимость, состояние проекта (общий срок реализации, когда и кто работал последний раз, сколько времени потрачено).

Технически задача сперва создается в Asana, потом прокидывается в TimeDoctor, а затем из TimeDoctor в Asana подгружается статистика по списанному на задачу времени.

И как это все объединяет ERP-система?

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

По каждому активному проекту компании мы видим:

  • Статус сделки

  • Тип сделки (по типу работ)

  • Задействованные участники

  • Кто трекал (списывал) время в этот проект

  • Общий бюджет проекта

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

Наша ERP - источник постоянных инсайтов для руководителей.

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

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

Если сотрудник возмущается, он, как правило, лодырь и бездельник.

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

Вверху - графики активности.

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

Один из важных плюсов - сквозная интеграция всех систем. Я могу в один клик перемещаться из ERP в Asana, amoCRM, в нашу B2B (в ней мы управляем готовыми решениями для amoCRM, модулями, виджетами, конкретными интеграциями к аккаунтам клиентов). И обратно. Везде есть обратные ссылки на источник данных.

Какие данные доступны в ERP

Начать надо с того, что доступы у всех разные. Линейные сотрудники видят 1/10 дашбордов руководителей. Но, раз мы говорим про управление компанией, буду рассказывать про максимум.

Рабочий стол - это метрики по сотруднику

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

Клиенты - дублированная база всех, с кем мы работали

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

Проекты - общий список всех проектов в производстве

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

Есть аналогичная вкладка по всем задачам с такими же возможности фильтрации.

Бухгалтерия - все закрывающие документы по проектам

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

Список сотрудников компании

Вся команда с должностями, ролями, контактными данными.

Отчёты - самая ценная вкладка для управления компанией

Отчет по проектам

Статус сделки, участники проекта, бюджет на проект, количество отработанных часов и сроки.

Отчет по сотрудникам

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

Отчет по клиентам

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

Отчет по зарплате и премии

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

Сотруднику они дают объективную аналитику собственной эффективности и возможность в режиме онлайн отслеживать объем заработной платы.

Отчет по конкретному сотруднику за июнь.

Любой день можно развернуть и увидеть поминутную занятость.

Чего нам стоила и стоит такая разработка

Нашей ERP-системе 2 полных года. На ее разработку мы потратили 2 490 часов сотрудников (топ-менеджмент, менеджеры проектов, собственник, сама разработка, тестирование, отладка).

Все данные мы храним, логируем, синхронизируем на собственном сервере. Обновление данных происходит раз в 5 минут.

Чтобы поддерживать такую ERP-систему нужны ресурсы:

  • активные пользователи, которые дают user experience, говорят, что работает плохо, а что хорошо;

  • поддержка технической исправности системы. Неизбежно возникают ошибки, мы фиксируем их в Asana и устраняем в рамках техподдержки;

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

Краткий обзор нашей ERP-системы мы делали в рамках первого занятия курса по внедрению Asana. В этом видео вообще есть довольно глубокий анализ всех инструментов, которые мы используем в бизнесе.

Для чего я вам все это рассказываю

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

Потому что самое дорогое в компании - время сотрудников.

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

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

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

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

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

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

Подробнее..

Перевод Многие дедлайны придумывают специально с целью заставить инженеров работать бесплатно

26.09.2020 20:04:42 | Автор: admin
Работа инженера сплошное разочарование. Возможно, потому что у нас нет власти, а менеджеры сбрасывают на инженеров все проблемы и ожидают, что они будут решены к вчерашнему дню.

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

Вот общий сценарий, который разыгрывается между инженером и его боссом, инженером-менеджером. Менеджер спрашивает, сколько времени займёт выполнение новой задачи. Бывает, что инженер не делал эту задачу раньше, поэтому честно отвечает, что понятия не имеет. Менеджер не принимает такой ответ и снова спрашивает. Тогда инженер даёт оценку практически наугад, а босс отвечает: Это слишком долго. Даже если инженер знает, сколько времени займёт выполнение задачи и даёт реалистичную оценку, менеджер часто отвечает: Это слишком долго. У тебя есть время до пятницы. Когда инженер спрашивает, как давно стало известно об этой задаче, босс отвечает, что месяц назад. Когда инженер спрашивает, почему он не сказал ему об этом месяц назад, тот просто смотрит на инженера, как будто не понимает вопроса.

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

Мне кажется, что такое взаимодействие между менеджером и инженером ни что иное, как игра. Либо для менеджера, либо со стороны компании. В первом случае это может быть демонстрация власти, а во втором реализация стратегии увеличения прибыли компании. Другими словами, если босс не совсем глуп (как иногда кажется), то он понимает, что инженер не может выполнить за три дня работу, которая занимает месяц. Но он играет по правилам компании: она хочет, чтобы инженер делал неоплачиваемую сверхурочную работу столько, сколько способен выдержать. Вот почему так много инженеров в некоторых компаниях работают по 70 часов в неделю.

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

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

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

Разработка в стартап-студии. Процессы, задачи, команда

08.09.2020 16:22:26 | Автор: admin
Станислав Сурский, CTO Admitad ProjectsСтанислав Сурский, CTO Admitad Projects

Это первый материал из серии про разработку в рамках стартап-студии. В первой части CTO Admitad Projects Станислав Сурский рассказывает про отличия в подходе к разработке разных компаний, о том, как все происходит в ADP и, само собой, как последние глобальные события повлияли на разработчиков.

Я могу сравнивать, как устроена разработка в разных компаниях. Работал разработчиком и в интернет-магазинах, и фрилансером, есть небольшой опыт в веб-студии. Так же плотно трудился ведущим разработчиком в антивирусном вендоре и там же был руководителем разработки. Очень часто приходилось работать с людьми, которые в разработке ничего не понимают и, самое главное, не прислушиваются к тому, что разработчик и техкоманда им говорят. У них бизнес-задачи и требования, они приходят: Дай мне вчера функционал. А такая разработка легко уляжется в годовой план И, самое главное, обратную связь не слышат. Им рассказывают парни-девелоперы не бывает чудес, есть воркфлоу: вот здесь планирование, декомпозиция, дальше анализ и самая малая часть, 30% это написание кода. В ответ: Нет-нет, это же легко, мне на прошлой неделе Вася-сосед точно такую же фигню делал за 2 недели, поэтому давайте, я в вас верю, мы сейчас с вами горы свернем!

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

В гигантах ИТ-индустрии есть другой нюанс. Там все зависит от позиции и направления, в котором ты работаешь. В какую команду попадешь. Можно прийти гребцом на галеру: тебя посадят у весла и ты будешь долгие годы мозоли натирать в одном направлении, совершая раз за разом, день за днем одно движение, а есть команды или проекты, где ты будешь Разработчиком. С потенциалом. Сможешь влиять на какие-то решения. И, конечно же, безумная бюрократия. Недавно собеседовал человека на техлида он работает в компании-подрядчике крупного телекома. Сейчас пилят личный кабинет для В2В., Он односложно отвечает на вопрос, почему уходит из компании -- бюрократия!. Как пример, миграция на более свежую версию фреймворк. Сам процесс написания кода, по его словам, занял, пусть, неделю, а утверждали и принимали решение о том, чтобы мигрировать, 9 месяцев. Это очень красочный и показательный пример.Эта ситуация мне видится не бюрократией ради бюрократии, а то что не те люди принимают решения. Выбор стека не должен уходить дальше технического директора, и то это когда парни, мы какую-нибудь дичь на новом проекте покатаем, надо смотреть, как проект будет развиваться в ближайшие полгода, и после этого решение должна принимать сама команда. Взглянуть немного в будущее и подумать, как мы это будем обслуживать. А когда это уходит на уровень людей, которые не будут решать проблемы технического характера с производительностью или с обслуживанием кода, то это теряет всякий смысл.

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

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

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

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

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

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

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

Месяцы самоизоляции, конечно, много чего у нас перевернули. В общем-то, мем про технаря, который сидел все время за компом и потом удивленно спрашивает: Карантин?! Какой карантин?! -- не хохма, а жизнь. Многие наши разработчики уже точно не вернутся в офис. Это не удаленщики, которые и брались изначально на удаленку, это именно те, кто до всего этого аккуратно приходил на работу, хотя присутствия от и до никто никогда не требовал. Когда все начиналось были опасения, что мы будем неэффективно работать, где-то будут просадки, но на практике не все так страшно. Половина разработчиков стала эффективнее работать именно из дома.Если по цифрам, то у меня прогноз такой. Из 100 % тех, кто ходил в офисы, я думаю, процентов 50 перестанет это делать, процентов 30 будут в офисе 13 дня в неделю. Оставшиеся 20% семейные и с детьми сказали, что будут фуллтайм.

Но лично для меня за это время пропала важная часть работы в офисе -- социальная. Нет быстрых минутных встреч, когда вместо того, чтобы поговорить 3 минуты с коллегой на кофепоинте и прояснить вопросы, ты назначаешь колл и 30 минут про это разговариваешь. У меня сейчас есть дни, когда я сажусь на свой любимый балкон в 9 утра и встаю в 10 вечера, и в промежутке я не делаю ничего, кроме как разговариваю с компьютером. В этом я вижу большой минус: нагрузки стало больше, потому что нет быстрых коммуникаций, теперь нужно либо написать, либо позвонить. Созвониться долго, переписываться тоже долго -- коммуникации стали долгие.

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

Подробнее..

Микроволновка, знающая о тебе всё что такое Интернет вещей (IoT)?

04.09.2020 14:06:16 | Автор: admin
С появлением на рынке стиральных машин, духовок, дверных замков и даже ваз с подключением к интернету, Bluetooth- или Wi-Fi-модулем в борьбу за интернет-потребителя включились не только разработчики ПО, но и промышленные дизайнеры. Так явление интернет вещей (Internet of Things) стал неотъемлемой частью нашей жизни.

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

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

image

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

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

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

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

image

Но есть и белые пятна в этом идеальном мире интернета вещей. Трудность состоит в том, как грамотно совместить разные платформы и устройства от разных поставщиков и при этом избежать риска утечки информации и их несанкционированного использования. Уже сейчас разрабатываются такие гибридные инструменты для работы на различных устройствах и платформах: Samsung SmartThings и Apple HomeKit для решений по смарт-домам; Dash и Mojio для интеллектуального управления машинами; Validic и Jawbone UP для контроля состояния здоровья.

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

В свою очередь, взаимодействие разработчиков с потребителями породило таких гигантов, как Instagram, WeChat, Uber и даже Angry Birds. Многомиллиардные бизнесы возникли из пожеланий потребителей, а не из идеи разработчиков. Таким образом, каждый может сделать вклад в то приложение, которым будет пользоваться. Это и есть основной стимул для роста интернета вещей.

Для создания продукта разработчики открывают доступ пользователям и потенциальным покупателям, чтобы предлагать, разрабатывать и использовать новые идеи для уже работающих платформ. Одними из таких платформ являются Apple CarPlay и Google Android Auto, которые дают доступ производителям автомобилей к своим технологиям.

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

Твиттер-конференция от Wrike киберпсихология на 280 символов

22.09.2020 22:05:57 | Автор: admin

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

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

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

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

Какая конференция и при чем тут твиттер?

Формат мероприятия очень простой. 29-го сентября в 17-00 начинаем твиттер-трансляцию в аккаунте @wriketechclub. Каждые полчаса один спикер рассказывает свой доклад через несколько твитов: 1 твит = 1 тезис доклада и слайд. Задавать вопросы, спорить и комментировать можно в треде даже после окончания твиттер-конференции: спикеры все равно никуда из Интернета не денутся :)

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

За лучшие вопросы мы разыграем книги по софт-скиллам и отправим в любую точку мира.

Чтобы ничего не пропустить, подпишитесь на наш твиттер. Ждем вас 29-го сентября в 17-00!

Подробнее..

Мы тратим годы на то, что делается неделю потому что все ларьки заигрались в IT-гигантов

31.08.2020 18:16:08 | Автор: admin


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

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

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

Чем больше пользователей становится у приложения, тем больше само приложение, чем оно больше, тем больше команда, и тем меньше вы понимаете, что и зачем делаете. Если у меня есть механизм из одной шестеренки, у которой надежность 50%, значит его надежность 50%. Если в нем две шестеренки, надежность будет 25%, а если шестеренок десять надежность будет близка к нулю.



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

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

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

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

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

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

Я люблю поработать в одиночку и быстро что-то собрать. Но я не разуверился и в идее вечной разработки. Она правильная для проектов, масштаба Windows или Chromium. При разработке калькулятора, эта идея чушь собачья. А если посмотреть на рынок вакансий, походить по собесам, то можно увидеть, что большая часть индустрии в РФ делает скорее калькуляторы, чем Windows.

Калькуляторы, но с Scrum/Agile, CI, CD, целым выводком продактов, гигантской кодовой базой, и сложным, кастомным дизайном. У меня есть теория, что так получается, потому что все хотят поиграть во взрослую разработку.



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

Это иллюзия, в которую мы играем, потому что на самом деле мы и не хотим делать пет-проект. Мы хотим играть в стартапщиков. И мне кажется, что маленький и средний IT бизнес в РФ из той же серии. Причем эта гадская система сама себя поддерживает. Вот изобрел ты интернет-магазин. Сделали концепт, бизнес пошёл, ты выпросил у инвесторов миллион долларов, и нанял большую команду. Они за пару лет напечатали тебе 300 тысяч строк кода, и система неплохо работает. Ты смотришь на эти тысячи строк, и думаешь ну раз мы их написали, и вроде бы отсюда ничего и не выкинуть, значит такая система и должна иметь такую большую кодовую базу.

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

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

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

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

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

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

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



На правах рекламы


Эпичные серверы это VDS для размещения сайтов от маленького интернет-магазина на Opencart до серьёзных проектов с огромной аудиторией. Представляем множество тарифных планов, где каждый найдёт нужное ему предложение.

Подробнее..

Как прошел открытый Demo Day в Райффайзенбанке

03.09.2020 18:19:12 | Автор: admin
Встретились онлайн 20 августа и рассказали подробнее о наших digital-решениях: девять команд Райффайзенбанка показали последние фичи и обновления от MVP голосового бота до подачи заявки на факторинг в семь кликов. Было много вопросов, делимся ответами и передаем впечатления с видео в статье!



Эффект присутствия


Прежде чем нажать на кнопку play у трансляции, немного погрузим в контекст:

> 9 команд, которые показывают demo решений онлайн (никаких презентаций!)

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

> возможность задавать вопросы

> интерактив: от спикеров вам прилетает опрос, и нужно угадать, какую долю вопросов уже закрывает бот в текстовом канале, или сколько клиентов воспользовались функцией формирования декларации?

Запускаем трансляцию



00:10:48 >>> команда Chat
Сейчас наш голосовой помощник внедрен в кнопочное меню и легко распознает запросы, например, открытие нового продукта, текущие тарифы или курсы валют. Показываем MVP голосового бота: чем уже скоро смогут воспользоваться наши клиенты при звонке в контакт-центр.

Остались вопросы к команде? Здесь отвечаем
> Какие fp либы используете для проекта, интересно послушать про применение fss(fs2)? Мы пишем не на Scala, а на Python, основная библиотека для FP у нас functools.

> Сколько времени в днях занял реализованный функционал? Голосовой бот переиспользует базовый функционал чат-бот-платформы, который был разработан за 3 месяца. В дальнейшем разработка ведется трехнедельными спринтами. Оценка задач на основе story points, поэтому оценка во времени некорректна. С точки зрения интеграции с решением телефонии, то это были цели двух спринтов.

> Есть ли софт от банка для умных часов? Также при общении с роботом. Мы пока такого не делали. Если увидим интерес обязательно сделаем.

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

00:30:23 >>> команда Leasing
Начинаем с красоты и показываем видео, как просто и легко оформить заявку на лизинг. И переходим к главному представляем новый раздел по субсидиям, где о каждом товаре можно прочитать в его персональной карточке.

Остались вопросы к команде? Здесь отвечаем
> Планируется ли интеграция продукта с ЛК юрлица? Да, мы планируем это сделать в начале 2021 года.

> Сколько времени потребовалось на разработку технической части сервиса? MVP 6 месяцев, в прод вышли за 12 месяцев.

> Нужно ли для оформления цифрового договора клиенту получать ЭЦП (электронную цифровую подпись)? Конечно, нужно.

> Есть ли возможность совершать выплаты регрессивно? Или только аннуитетно? Такая возможность есть.

> В чём преимущество в лизинге именно в Райффайзенбанке? Или лучше получить предпринимательский кредит? Кредит, в основном, для развития или для оборота. Лизинг это все-таки инструмент обновления основных средств.

00:51:15 >>> команда RBO lite
Добавили удобный функционал для юридических лиц. Теперь наши клиенты могут отслеживать свои поступления и списания по счетам в новом управленческом виджете. В нем есть разбивка по категориям, и смотрится он гораздо приятнее, чем обычная выписка.

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

> Будет ли статистика со сравнениями трат по категориям, как пример: в августе на транспорт столько-то, в сентябре на транспорт на столько-то % меньше или больше? Надо изучать этот вопрос: провести опросы, интервью, запустить A/B-тесты. Может оказаться так, что для физлиц этот функционал более актуален, чем для малого бизнеса. И тогда встает вопрос, а точно ли это нужно делать? Но в целом это гипотезы, которые нужно валидировать.

> Сколько времени ушло на разработку MVP? Две недели: от идеи до прода. Помогло, что рабочая модель категоризации уже была.

> Есть ли у личного кабинета юрлиц API, или он планируется для возможности интеграции с системами предприятия? В настоящее время открытого API нет. Есть возможность интеграции Host-to-host.

> Планируется ли задизайнить категории более интересно? Что для вас более интересно? Тут скорее приглашение к дискуссии, можем обсудить в комментариях к записи :)

> 5000 это разве репрезентативная выборка? Достаточная, чтобы понять как функционал влияет на клиентский опыт.

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

> Можно ли выставить фильтр по категориям и применить его на заданный период? В MVP нельзя. Насчет системы фильтрации подумаем при реализации целевого решения.

01:08:29 >>> SME Digital
Проработали простой и понятный интерфейс для заказа справок и выписок онлайн. Сервис организован по принципу интернет-корзины. Вместе сравним функционал до/после и оценим преображение.

Остались вопросы к команде? Здесь отвечаем
> А если клиент удаляет один и тот же текст, то может, в N раз предлагать ему уже без этого текста шаблон? Мы поступили более кардинально сделали новую форму заказа справок, где не нужно редактировать запрос на справки. Так ускорился и сам процесс подготовки: запрос на справки теперь приходит в банк не как документ с текстом свободной формы, а как структурированный документ.

> Когда подпись документа происходит с помощью смс, то какой удостоверяющий центр вы используете? Клиент подписывает запрос на справки с помощью ПЭП (простой электронной подписи)

> Будет ли добавлена в дальнейшем в заказе справок форма для нестандартной справки? Нестандартную справку всегда можно заказать, написав письмо в банк через интернет-банк для бизнеса (РБО).

> На сколько сократился % запросов с ошибками после внедрения? Это мы узнаем в самое ближайшее время, когда будет достаточный объем данных для статистики. Ведь данный сервис для клиентов микро и малого бизнеса мы запустили недавно 26.08.2020.

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

> Формирование самих справок автоматизировано, или так же сидят люди и собирают корзину? Формирование справок полностью автоматизировано.

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

> Зависит ли цена курьерской доставки от адреса? Нет, не зависит.

> Если требуется заказать справку, которой нет в списке? Если в списке нет необходимой справки, ее всегда можно заказать, написав письмо с темой Заказ справок из интернет-банка для бизнеса.

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

01:29:45 >>> R-Online
Показываем функционал для новых клиентов: пользователь может обратиться к нам через мобильное приложение, чтобы получить продукт или услугу. При этом у него еще нет данных для авторизации, поэтому процесс подачи заявки происходит из неавторизованной зоны мобильного банка.

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

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

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

> Вход по face/touch id есть? Да, в приложении есть поддержка биометрии.

> Есть ли экспорт данных о расходах в личный кабинет? Да, вы можете осуществить экспорт данных о расходах в веб-версии интернет-банка. В мобильном приложении эта функциональность пока отсутствует.

> Как часто релизы мобильного приложения iOS? Мы стремимся максимально сократить релизный цикл, поэтому выпускаем релизы один раз в 2 недели.

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




01:50:55 >>> Digital Lending PI
Стремимся к самому быстрому оформлению кредита онлайн в один клик, и для этого разработали интеграцию с Госуслугами, которая помогает заполнить большую часть заявки сразу. Ещё одна фича процесс оформления кредита без звонка информационного центра. Наши клиенты могут сами выбрать понравившееся предложение, назначить удобное место и время встречи с курьером.

Остались вопросы к команде? Здесь отвечаем
> Как у вас устроена процедура проверки клиента со стороны департамента рисков? Процедура проверки по большей части автоматизирована, процесс этот достаточно объемный и достоин отдельной статьи :)

> Запрашиваете ли вы кредитную историю? Если да, то как именно? Да, мы запрашиваем кредитную историю в БКИ в тех случаях, в которых у банка есть право на такой запрос согласно действующему законодательству.

> Долго ли интегрировались с Госуслугами ? Наша команда не интегрировалась сама непосредственно с Госуслугами, делали это через единый банковский узел, поэтому интеграция заняла не так много времени не более 2 спринтов (4 недель).

> Как у вас устроен CI/CD небольших сервисов по типу приведенного лендинга по заказу кредита? Для сборки и деплоя мы используем Bamboo.

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

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

> Как вы проверяете корректность клиента/данных при оформлении кредита? Для этого мы используем набор запросов, в том числе и запросы в БКИ. У нас уже была осуществлена подобная интеграция заявки в чат-боты в популярных мессенджерах, vk, viber, telegram.

> На каком поле обычно происходит отказ, уход пользователя со страницы? Есть две основные точки ухода пользователя со страницы паспортные данные и информация о работе (в частности, о заработной плате).

> Планируете ли этот функционал добавить в мобильное приложение? Функционал предзаполнения заявки не совсем актуален для существующих клиентов. Для новых клиентов мы хотим в будущем году реализовать процесс подачи и получения кредита через мобильное приложение.

> А если справки 2-НДФЛ нет или она онлайн? Есть вероятность, что клиенту сообщат о том, что справка 2-НДФЛ не потребуется. В иных случаях, ее необходимо предоставить, банк принимает и иные способы подтверждения дохода, в том числе справку по форме банка и выписку из ПФР.

> Как банк обрабатывает брошенки на разных этапах заявки? Банк отправляет три SMS с follow-up со ссылкой на уже частично заполненную заемщиком заявку через час после того, как заемщик ушел со страницы, и в течение следующих трех дней.

> Написано, что нужен один документ и без справки, а в подтверждении написано что нужна справка? Мы действительно выдаем кредиты без справок до 300 000 рублей, по умолчанию мы просим на форме подготовить справку 2-НДФЛ. В случаях, когда клиенту нет необходимости нести справку, мы сообщаем ему об этом во время звонка. Сейчас мы работаем над тем, чтобы потенциальный заемщик узнавал об этом в процессе заполнения формы.

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

02:10:45 >>> SME Transactional
Упрощаем жизнь наших клиентов микро и малого бизнеса: поработали над профилем пользователя в интернет-банке, через который можно внести изменения новый номер телефона, адрес или данные об увеличении уставного капитала. Всё это онлайн, без посещения отделений.

Остались вопросы к команде? Здесь отвечаем
> Как вы валидируете/проверяете данные на корректность и действительность? Данные сверяем с данными выписки из Единого госреестра и иных доступных источников.

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

> Если клиент не может в моменте подтянуть фото, будет ли сохранен шаблон или заново вводить данные? Шаблон сохраняется до момента подписания.

> Как долго работает сервис уже? Проводили ли аналитику по самым востребованным изменениям? Сервис в текущем формате запустили в марте. Самым востребованным стал функционал по продлению полномочий.

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

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

> Есть ли оповещение клиента о том, что данные изменились (почта, приложение)? Клиент видит баннер в интернет-банке с информацией о том, что изменения приняты, и обновлённые данные в своём профиле.

> Планируете ли добавить доверенности в профиль? Да, есть такие планы.

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

> Если у вас интеграция с ФССП в части обмена данными о юрлицах? Нет.

> Результаты заботы о клиентах впечатляют. Интересно, какое количество пользователей использует данную услугу? Насколько активно клиенты вовлекаются в использование новых фич? 40% клиентов интересовались функционалом. Видим, что визиты в отделения с целью сообщить об изменении сведений сократились на 40-60%.

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

02:28:08 >>> Factoring
Проходим путь клиента с момента подписания документов до получения финансирования на расчетный счет. Процесс автофинансирования стал быстрее благодаря интеграции с Контур.Факторинг: все отгрузочные документы подтягиваются внутри одной площадки.

Остались вопросы к команде? Здесь отвечаем
> Хорошо, пекарю нужны средства на изюм, муку, зарплату. А почему бы ему просто не взять у вас кредит? :) В большинстве случаев по кредиту требуется залог и/или поручительство, что сможет предоставить не каждый пекарь. Помимо этого, зачем ему увеличивать свою кредитную нагрузку и тратить колоссальное время на процесс установления кредитного лимита, если можно получить факторинг за 5 дней по 5 документам.

> Как работает интеграция с Контур, используется ли брокеры очередей, и если да, то какие? Контур.Факторинг предоставляет API для работы. Наш сервис обращается ежеминутно за новыми поставками и, если находит такие, передает по цепочке сервисов к клиенту. Брокеры очередей не используем.

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

> Выведены ли у вас на мониторы интеграционные взаимодействия, чтобы отслеживать ошибки трафика? Может быть в Grafana? Да, мы используем Grafana, но реагирование на возникновение ошибок происходит автоматически с помощью Zabbix. Также проверяются жизненные показатели сервиса в фоновом режиме (CPU, RAM, Network).

> С какими платформами планируете работать в будущем? Открыты для всех платформ, которые могут предоставить ценные данные для одобрения сделки.

> Интегрироваться с вами можно по открытому API? Пока что нет, но, если нам поступит такая просьба от клиентов, конечно же, сделаем.

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

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

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

> У вас обе стороны могут увидеть эти документы? Да, доступ в личный кабинет RFO может получить как клиент, так и дебитор. Аналогично и в приложении Контур.Факторинг.

> Какие условия для получения финансирования для новых клиентов? Условия зависят от дебиторов, передаваемых на факторинг, запрашиваемых лимитов, отсрочки платежа по контракту и прочих факторов. Напишите нам, чтобы начать работу по факторингу: Factoring_sales@raiffeisen.ru.

02:50:25 >>> SME Finance
Показываем формирование декларации, выпуск квалифицированной подписи и отправку документа в ФНС. Всё это быстро и легко через мобильное приложение на Android. Эта функция доступна не только в интернет-банке, но и в мобильном приложении.

Остались вопросы к команде? Здесь отвечаем
> Поддерживаете ли другие ОС, помимо Android? Да, помимо Android онлайн-бухгалтерия доступна пользователям приложения на IOS и в web-версии.

> Где хранится облачная подпись? Создание и хранение ключей электронной подписи пользователей осуществляется на стороне АО Калуга.Астрал с использованием специального защищённого модуля КриптоПро HSM. Каждый пользователь получает доступ к своим ключам после прохождения процедуры надёжной многофакторной аутентификации в КриптоПро DSS с использованием мобильного приложения КриптоПро myDSS.

> Сообщить о новых персональных данных можно также в приложении или необходимо идти в банк? Идти в банк нет необходимости. Для изменения данных нужно написать письмо с темой Изменения учредительных/идентификационных документов/условий обслуживания РКО. Это можно сделать через приложение.

>Уменьшить объем текста не планируете? Многие ли его читают в таком формате? Делали тепловую карту? Текст согласован с юристами, пока над уменьшение объема не думали. Тепловую карту не делали. Спасибо, что подсветили этот момент, проведем аналитику.

> Как представлено и реализовано тестирование функционала в команде? В команде есть выделенные роли тестировщиков. Коллеги пишут автотесты, а также тестируют функционал вручную до вывода в прод. В проде первыми пробуют новую функциональность наши знакомые ИП.

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

> Сколько длится проверка декларации (максимум)? В основном проверка длится 1-2 дня, но максимум в нашей практике был месяц.

> myDSS стороннее приложение? Или это приложение от партнера? myDSS стороннее приложение, совместная разработка компаний КриптоПро и SafeTech.

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

> Как долго проводили интеграцию с ФНС? Прямой интеграции с ФНС в части сдачи отчетности не делали. Выпуск подписи и отправка отчетности осуществляется через партнера АО Калуга.Астрал. Полную интеграцию с АО Калуга.Астрал сделали примерно за 3 месяца.

> Можно ли подтянуть данные из других банков? Нет, информацию из других банков подтянуть нельзя.

> А если в декларации допущена ошибка, её корректировка выполняется в вашем интерфейсе или в Личном кабинете ФНС? Если в декларации допущена ошибка, то ФНС присылает извещение о корректировке. Извещение отображается в онлайн-бухгалтерии. Пользователи могут сформировать корректировку также в онлайн-бухгалтерии. Идти в личный кабинет ФНС не нужно.

> Интеграция выпуска подписи в ДБО будет? Выпуск электронной подписи доступен клиентам в web-версии интернет-банка (RBO) и в приложении на Android. В ближайшее время функционал появится также в приложении на IOS.

Спасибо, что присоединились к нам



Были рады видеть вас среди зрителей Open Demo Day #2 в Райффайзенбанке! У нас получился крутой обмен опытом.

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

>>> Хотим встречаться ещё чаще: на нашем аккаунте в Timepad всегда ждем вас на открытые мероприятия.
Подробнее..

Из песочницы Как оцифровать разработчика или коротко о том, как сделать работу разработчиков более прозрачной для Компании

19.09.2020 22:22:49 | Автор: admin

Преамбула


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


Предыстория


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


Проблема


Все в этом процессе было отлично за исключением одного момента, а именно согласования Аналитиком сроков разработки с Заказчиком владельцем продукта Интернет банк юридических лиц, каналы web+mobile, далее будем называть его просто Заказчиком. Заказчик всегда понимал и принимал работы, которые проходили у него на глазах или с его участием, а именно:


  • Уточнение и формализация его требований. Он непосредственно видел, как из его 2-х строчек текста рождается клиентская история, прототип, и наконец, постановка для разработчика.
  • Все виды тестирования. Он видел огромные списки тестов.
  • Документирование. Он мог посмотреть на количество страниц текста и картинок(схем).
  • А вот в части разработки заказчик всегда чувствовал подвох, ему казалось, что злобный(а на самом деле добрейшей души человек) бородатый тимлид, давший свою оценку, только и видит, как вписать туда процентов 50 лишних часов, не утруждаясь уложиться в SL и получить мотивацию по KPI. Эту проблему и пришлось решать молодому Руководителю.

Решение


Шаг 1. Как в абсолютных значениях рассчитать длительность разработки

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

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

Что, если не брать задачи целиком, а каждую разделить на конечные составляющие работ для нашей системы(системой, на протяжении всей статьи, будем называть Интернет банк юридических лиц, каналы web+mobile)?

В нашем случае получилось так:

  1. Изменение верстки страницы
  2. Создание новой документарной страницы
  3. Доработка формы, вывод нового поля формы из БД
  4. Типовой контроль
  5. Сложный контроль (сложный нетривиальный алгоритм)
  6. Расширение схемы БД
  7. Скрипт СМС рассылки
  8. Скрипт для рассылки по ЭП

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

Для оценки трудоемкости каждого блока была придумана единица стандартная единица трудозатрат(СЕТ, s). СЕТ это абстрактная мера измерения трудоемкости, она не имеет под собой физического смысла, можно назвать как угодно. Путем ретроспективного анализа(за последние 3 месяца), мы(я, аналитик по системе и тимлид) разбили все задачи на конечные составляющие и пропорционально оценили трудоемкость каждой из них(si), результат в таблице(табл.1).



Теперь каждую задачу мы могли оценить в СЕТах, например:

  1. Задача: реализовать форму обратной связи на главной странице системы, которая появляется у клиентов, не давших обратной связи. На форме отображены:
    • шкала оценки в форме звездочек, кликом по которым можно дать оценку от 1 до 5,
    • поле ввода в свободной форме длиной 500 символов,
    • кнопка отправить, по нажатию на которую осуществляется запись данных в соответствующую таблицу БД, закрытие формы без перезагрузки страницы.
  2. Детерминация на простейшие действия, согласно табл.1.:
    • Создание таблицы в существующей БД, написание логики отображения формы 0,2 СЕТ
    • Верстка формы, 2 поля + проверка на заполненность 1 СЕТ
    • Написание асинхронного запроса к серверной части, написание серверной функции записи в БД, 1 СЕТ
  3. Расчет трудоемкости в СЕТах: 1+1+0,2=2,2 СЕТ

После этого, был введен термин производительность(p), который определяет производительность каждой категории разработчика(Табл.2)



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



продолжим на нашем примере

4. Определение длительности работ, для сотрудника категории Senior:
2,2(СЕТ)/1,5(СЕТ/день)=1,6 дней
Длительность 1,6 дней


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

Методика оценки так понравилась Заказчику, что он предложил оценивать остальные этапы работ:

  • уточнение требований
  • планирование реализации
  • тестирование и документирование

в пропорциональном отношении от времени разработки, так были введены следующие коэффициенты (Табл. 3):



Теперь была возможность оценить длительность каждого этапа:



всю длительность внесения изменений в систему, по формуле:



например:

4. Определение длительности работ, для сотрудника (аналитик и разработчик) категории Senior:

0,2*2,2/1,5+0,3*2,2/1,5+2,2/1,5+0,2*2,2/1,5=0,3+0,44+1,6+0,3=2,64 дня
Длительность 2,64 дня



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

Перевод Использование семи смертных грехов для мотивации персонала

22.09.2020 18:18:39 | Автор: admin
Привет, Хабр! Представляю вашему вниманию ироничную вариацию на тему семи смертных грехов. На этот раз, в контексте управленческих практик. Перевод статьи Evil Coach.

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

image


Некоторые руководители пытаются выстраивать взаимодействие между командами и мотивировать сотрудников, но настоящий босс привык активно управлять трудовыми ресурсами. Вот стратегия сохранения контроля, основанная на многовековом опыте. Некоторые говорят, что контроль над трудовыми ресурсами иллюзия но они просто никогда не работали под началом настоящего босса. Секрет контроля использование семи смертных грехов для мотивации ВАШИХ трудовых ресурсов. В конце концов, это именно то, что всегда двигало людьми, не так ли? Тогда приступим.

Гордыня


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

Жадность


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

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

Зависть


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

Чревоугодие


Разработчики питаются колой и пиццей, правильно? Убедитесь, что ваши команды имеет постоянный доступ к этим столпам здорового питания. (Время от времени можно раздавать витамины, если у них начнут выпадать зубы, или жидкость для полоскания полости рта с фтором, если зубы начнут разрушаться, ну, вы поняли идею.) Если вы обеспечите их едой и напитками, им будет не нужно ходить на обед. Если в офисе установить узкие дверные проемы, дополнительным бонусом через некоторое время станет то, что они вообще не смогут оттуда уйти. А значит у вас появятся ДЕЙСТВИТЕЛЬНО преданные своему делу сотрудники.

Гнев


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

Лень


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

Похоть


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

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

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

Удачи!
Подробнее..

Из песочницы Удаленка. Работающие принципы управления

21.09.2020 16:09:27 | Автор: admin
Подул вирус и мир сильно изменился. Слово удаленка во многих компаниях из далекой мифической абстракции превратилось в реальность. Реальность иногда милую, а иногда уродливую и странную. Особенно в России. В статье я описываю управленческие принципы, позволяющие эффективно организовать работу удаленную работу команды.


В штатах удаленная работа уже очень давно не диковинка. Году так аж 2003 наш РП на одном из митингов во время обязательного вступительного small talk проговорился, что сидит в своем доме в Калифорнии в одних трусах. Потом ему это несколько месяцев припоминали, а я сам, находясь on site в славном штате Айова, стал свидетелем живой невербальной реакции бизнеса на такое откровение. Все это безобразие происходило не с гаражным стартапом, а между вполне солидными компаниями. РП был от IBM, проект для одного из крупнейших штатовских банков.

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


С того момента много воды утекло, но так получалось, что весь мой был связан именно с работой в и организацией работ удаленных команд. Долгое время я сотрудничал с компанией Vega ECM Solutions, чьей особенностью было выполнение проектов территориально распределенными командами, где все сотрудники работали из дома. Даже когда компания открыла очень приличный офис в Irvine CA, он чаще всего был пустым и выполнял скорее представительскую функцию. Люди предпочитали работать из дома, а руководство этому не препятствовало. А зачем, когда все хорошо и эффективно работает?

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

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

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

Принцип 1. Работать строго по задачам в трекере


Принцип очевидный, примерно такой-же, как необходимость мыть руки. Однако, как руки моют далеко не все и не всегда. До сих пор в некоторых компаниях какое-то число задач проходит мимо трекера. Или задачи как-бы в трекере, но не всегда соответствуют тому, что реально делается. Если при офисной работе это еще как-то допустимо все на виду, то при удаленке трекинг всех значимых задач обязателен. Что-такое значимая задача определяется эмпирически. Мой критерий любая задача, которая не может быть сделана за 15 минут. При этом с таймером стоять не надо. Если на какую-то консультацию, разбор ошибки и т.д. вдруг потребуется не 15, а 16 минут, или даже 17, то она вполне может не попасть в трекер, при условии, если таких задач немного. Аналогично и в другую сторону. Если на задачу требуется 5 минут, но за эти 5 минут разработчик делает изменение к коде, то такая задача быть зарегистрирована. Иначе как вы через год определите, зачем это вдруг поменяли вот эту строчку кода?

Какой трекер использовать? Ответ любой, к которому привыкли и который удобен. Мои команды работали с жирой. Редмайн также вполне подойдет. Да даже и Trello.

Но

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

А если получается наоборот все очень сложно, то простая и хорошая идея работать по трекеру ломается. Конечно, команда что-то трекает, но в минимальном объеме, чтобы отчеты не испортить

Вредная мысль А что если реальный рабочий трекинг вести в альтернативной системе? Trello, например.

Принцип 2. Ежедневный отчет по затраченному времени


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

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

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

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

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

Внедряя принцип учета времени во многих командах, я всегда слышал один и тот же вопрос-утверждение в разных творческих вариантах "мы теперь вместо разработки будем все время тратить на списание времени". Вполне может быть. Вы имеете полное право учесть время, затраченное на списание во времени выполнения задачи. Легко посчитать сколько времени требуется на то, чтобы залезть в жиру, найти задачу, прикинуть сколько времени заняла задача, что делалось и вписать несколько цифр и пару фраз? Пусть 5 минут. Разработчик редко работает более, чем над 5 задачами в день. Итого, в худшем случае на списание времени будет потрачено 25 минут. Компания может себе это позволить.

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

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

Как делать не надо...

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

Принцип 3. Регулярные планерки команды


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

Я назвал такие регулярные митинги команды планерками, а не скрамовскими дэйли вполне осознанно. Скрам это одна из методологий, эффективная в одних ситуациях, но совсем неприменимая в других. Натягивать скрам на все живое затея странная и непонятная.
Поэтому именно "планерки", хотя по смыслу и формату они и напоминают дэйли. Обсуждаем статус, вводные. Объемные вопросы переносим в отдельные совещания. Длительность рекомендую ограничивать 15-30 минутами. Оптимальная периодичность в спокойное время 2-3 планерки в неделю, в горячий период раз в день.

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


Принцип 4. Коммуникации 1х1


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

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

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

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

Ничего же сложного.
Подробнее..

22 сентября, Онлайн-митап Product Engineering Meetup 2 Культура разработки

17.09.2020 16:18:03 | Автор: admin
22 сентября мы проводим онлайн-митап Product Engineering Meetup #2 Культура разработки в продуктовых компаниях.

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

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

Спикеры инженеры и менеджеры продукта из Badoo, ManyChat, Додо Пицца и Работа.ру. Будем говорить о том, какие практики помогают командам создавать качественные продукты. Обсудим, какие процессы разработки помогают фокусироваться на донесении ценности пользователям и соблюдать сроки. Рассмотрим, как находить компромисс между бизнесом и разработкой и определять границы ответственности.

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

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



Доклады


История эволюции фичи: от MVP до одной из основных функциональностей продукта Евгений Жуков, Backend Developer (ManyChat)

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

Как перестать беспокоиться и начать верить А/Б тестам 2 Максим Кислов, Frontend Engineering Manager (Badoo)

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

  • как организовать работу с А/Б тестами внутри компании;
  • как дать бизнесу ответ на вопрос ну как там наш тест?;
  • как определить границу ответсвенности техлида и разделить ответственность с продактом.

Инициатива не наказуема. Почему разработчика важно погружать в продуктовую жизнь Лаша Харчилава, Ведущий Менеджер Продукта (Работа.ру)

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

Как релиз продукта вышел на полгода позже, а пересмотр процессов разработки научил нас попадать в сроки Борис Герн, B2C Product Lead (Додо Пицца)

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

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

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

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

Участие


Встреча пройдёт онлайн, 22 сентября. Начало в 19:00.

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

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

Категории

Последние комментарии

© 2006-2020, personeltest.ru