Release is coming
Мой психотерапевт: уведомления из приложений не могут вызывать чувство паники.
Уведомления:
Мой психотерапевт: уведомления из приложений не могут вызывать чувство паники.
Уведомления:
Добрый день, дамы и господа.
Искал по тегам сообщество Тематическое - не нашел (*хотя думал, что такое тут есть).
Интересует контакт PM со стороны яндекс-такси. А к ним, буквально, один вопрос - когда будет в API интерфейс для добавление пользователей в диспетчерскую? Этот вопрос в кулуарах уже поднимался и обсуждался. Просто застопорился. В телеге есть Максим С. Как я понял - PM со стороны яши. Но он не отвечает.
ps у нас продукт для таксопарков и очень нужен данный функционал. А так как мы работаем не только я яндексом, но и с диди в частности, то таких "интеграторов" яндекс, как бы, не любит. Из-за диди.
*Была волна негатива со стороны яндекса. Если парк (таксопарк) на одно юр лицо открывает и диспу в яше, и в диди, то яндекс эту диспу блокировал по надуманным причинам. Некоторых наших клиентов это коснулось. Нас на этой же волне не взлюбил, видимо. Возможно именно поэтому я со своим вопросом (про необходимость добавления водителей через API) остаюсь без ответа. Может есть еще какие-то причины, но мне не ведомые.
В общем хотелось бы кого-то найти с той стороны, кто хотя бы ответит на вопросы и уточнит "официальный" статус наших отношений. Всем спасибо.
Вследствие поглощения нашей нефтехимической компании газовым концерном есть неиллюзорный риск остаться без работы в течение полугода. Знакомый из Иннополиса посоветовал рассмотреть позицию Product Owner, так как у меня есть опыт в 2 года руководством небольшого коллектива. Минус в том, что я вообще в IT не бывал и поэтому есть сомнения по поводу этой позиции.
Есть курсы, в том числе государственные на эту тему (product owner, product manager и аналогичные), и я готов обучаться. Но и тратить полгода возможно впустую нет желания. Начал самостоятельно читать и вести конспекты по указанным в заглавии темам. В целом пока тема интересная и перспективная.
Так вот. Просьба знающих людей подсказать, насколько сложно будет человеку со стороны стать PO, если опыта в АйТи совсем нет. Насколько я понял, часто PO делают из команды разработчиков, так как у человека есть понимание хоть какое-то в процессах. У меня же Есть силы, желание, время пока что, просто хочется направить куда-то весь свой вектор.
Сильно не минусуйте, пост без рейтинга.
Upd и стоит ли идти на курсы за 270к за полгода обучения или государственные программы дают аналогичные знания.
Всем лучи добра! Меня зовут Николай Петров, но вы можете звать меня просто Вадим. Я работаю техническим писателем в одной компании компании. Мы разрабатываем систему электронного документооборота, а в статье я хочу поделиться тем, как мы один большой отдел поделили на несколько команд. Я не буду пересказывать очередную историю успешного успеха, а изложу процесс с моей субъективной точки зрения. Всё перевру, приправлю тупыми шутками и в таком духе.
Как у любой другой компании у нас была своя команда разработки, точнее две больших команды. Одна команда разрабатывала один продукт, другая — второй. Всё шло хорошо, приходили новые разработчики, команды постепенно разрастались, и к какому-то моменту стало понятно, что большие команды только усложняют процесс разработки и делают взаимодействие неудобным. Когда одни и те же ошибки исправляются по несколько раз разными людьми — это субоптимально. Также субоптимально, когда на утреннем стендапе 22 человека и пятиминутный разговор о проблемах выливается в получасовой сеанс психотерапии для одного-двух разработчиков. Так мы решили перейти от проектных команд к кросс-функциональным командам. Сейчас всё поясню.
TRIGGER WARNING: Прежде, чем я начну, прошу вас подготовиться к неожиданностям при прочтении статьи. Если текст кажется вам переполненным сарказмом, пожалуйста, не относитесь к нему слишком серьёзно. Если текст вас оскорбляет, не читайте его. Спасибо!
Сам понял, что сказал?
Сложное слово "кросс-функциональные" означает всего лишь, что все команды занимаются всем понемногу. Таким образом каждая команда выполняет задачи из разных проектов и владеет знанием обо всём продукте, а не только о его части. Почему так важно, чтобы каждый знал чуть-чуть обо всём, думаю понятно, но на всякий случай поясню:
- Каждый разработчик видит код разных проектов и немного понимает "как это устроено".
- Если кто-то заболел, ушёл в отпуск или уволился (и такое случается), кто-то другой подхватит его работу.
- Все вместе делают продукт, а не отдельную его часть.
Недолго думая, мы решили организовать встречу в лучших традициях демократии, где каждый может сам выбрать, что ему нравится больше всего. Встречу провели, конечно же, онлайн. Не все сейчас ходят в офис, да и офисы у нас в двух разных городах. Кто-то даже впервые показал своё истинное лицо. Не только аватарку, в смысле. Все дружно перешли по ссылке в Miro, где наш заботливый руководитель Денис заранее подготовил стикеры, на которых каждый записывал, чем он хочет заниматься.
Затем всем было предложено занять место за четырьмя столами. Столы были виртуальные, поэтому закусок не предполагалось, зато каждое место было подписано в духе "frontend-разработчик", "backend-разработчик", "бизнес-аналитик", "тестировщик", ой, простите, "QA-инженер", "технический писатель". Три обычных команды и одна типа сервисная — помогает другим и координирует работу. Всё потому, что бизнес-аналитиков у нас пока не так много да и технический писатель всего один (это я. Привет, мам!).
Где-то после этого была ещё встреча для каждой команды, где они долго и в лучших традициях древнегреческих мудрецов рассуждали о том, кто же должен быть "тимлидом", а кто должен ходить на общекомандные встречи и почему это могут быть разные люди.
После разделения каждая команда обладает всеми необходимыми атрибутами успешного коллектива:
- Дурацкие названия: Вжик, Горыныч, БЭМС (Боевые, Энергичные, Молодые, Симпатичные), Звёздочка
- Логотипы из картинок, найденных в интернете
- Командный дух, компетенции и опыт
Передел YouTrack
Команды есть, теперь надо как-то работать. Работаем мы в YouTrack, точнее с его помощью. Да-да, я знаю, что Agile, спринты, ежедневные стендапы и вот это всё от зарубежного диавола и вообще никому не надо. Если вы согласны, то пропускайте этот раздел и идите лесом дальше по статье.
Постараюсь кратко и на пальцах. Раньше у нас был один общий ютрек: все задачи в одной куче, которая распределялась нашим многозадачным руководителем Денисом. Теперь у нас по-прежнему один общий ютрек, но задачи распределяет маленький избранный народом тимлид.
Раньше каждые две недели мы планировали один общий спринт, на котором можно было просадить полтора часа времени, а теперь команды планируют спринты сами. А могут вообще отказаться от всего лукавого аджайла и планирования, если так проголосуют. Профит в том, что теперь на планирование тратится значительно меньше времени и нервов.
Мне так вообще в планировании не надо участвовать. А смысл? Всё равно каждое требование я потом должен буду задокументировать, вот я и документирую, а не планирую.
Раньше в ютреке было два проекта: платформа и web-клиент. Теперь у нас есть общие задачи производства, которые могут включать любой проект. Были задачи типа WebC и задачи DV5, а стали просто TSK (может быть как WebC, так и DV5, так и вообще что угодно). Раньше ошибки записывались как обычная задача, а теперь в специальную задачу типа ERR. Видишь заголовок и сразу понимаешь, где собака зарыта.
У каждой такой задачи есть поле "команда", в котором указаны ответственные. Приходишь такой в требование, смотришь, кто ответственный, сразу знаешь, на кого наехать, чтобы узнать инфу.
А ещё у меня появился свой тип TSK-задачи — задание на документацию. У моих особых задач нет ревью и тестирования, они сначала открыты, потом в работе, потом закрыты. Всё.
Расскажи ещё, как у вас круто получилось
Работать правда стало намного увлекательнее. Появился чёткий ритм. Утром стендап (5-15 минут) и обсуждение командных проблем, потом избранные приходят на синхронизацию и рассказывают проблемы на общекомандной встрече (обычно минут 5-7). Каждые две недели ретроспектива (как поработали) и планирование (что будет делать дальше) и общекомандное демо (показать всем, как работает сделанное за 2 недели). И это не полуторачасовые встречи как раньше, а реально динамичные и полезные события. Мне особенно нравится демо, потому что теперь мне не надо сидеть и втыкать в требования часами, включая воображалку "а что же тут подразумевалось? а как же это задокументировать". Команды всё покажут и объяснят сами!
Ладно, кого я обманываю, всё равно мне приходится втыкать в требования часами, потому что я тупой.
Команды стали максимально автономными и независимыми. Они не ограничены ничем кроме достижения поставленной цели — выпуск продукта. В своих маленьких коллективах коллеги разработали свои методики автоматизации, особенные алгоритмы взаимодействия и т.д. Например, в Звёздочке разработали систему ачивок за количество закрытых требований в спринте. Если они закроют XX, YY, NN требований, то получат одну, вторую и третью звёздочку соответственно. Причём именно полностью закроют, включая документацию. На вопрос "а что если я не успею задокументировать их требование, и оно не будет закрыто", мне ответили, что могут вежливо попросить меня поторопиться. Что даёт мне некоторую власть над целой командой. Власть опьяняет.
В любом случае получилось классно! Демократичность, открытость и самостоятельность — вот как бы я охарактеризовал нынешний процесс.
Гонишь, не может всё быть так гладко
Может и гоню, но совсем чуть-чуть. Вот настолько:
Дело в том, что у нас в компании налажено ревью кода. Это когда один разработчик приходит к другому и говорит: "смотри, какой классный код я сделал!", а второй ему отвечает: "почитай чистую архитектуру Мартина, тогда поговорим".
Короче, у нас было несколько вариантов организации ревью, и мы не знали, какой из них выбрать:
1. Итеративное ревью.
--- Взяли задачу. Ответвились, сделали доработки по фронту и по бэку.
--- Перед передачей на приёмку бизнес-аналитику делаем ревью фичи целиком. Заодно подмержили develop.
(Есть мнение, что разработка в отдельных ветках — это прошлый век. Вот и пусть будет.)
--- Сделали хорошо, довели ревью до одобрения и передали на приёмку.
--- Если нужна доработка, повторяем предыдущие пункты.
--- Если доработка не требуется, передаём на тестирование.
--- Проводим багфикс.
--- Когда готовы, делаем ревью изменений по багфиксу в целом, обратный мерж и вливаем в develop.
Вот видите, всё просто!
В таком случае ревью будет чуть масштабнее и сложнее, но делать его нужно будет реже. Одна команда сможет ревьюить другую, будет коллективное владение кодом, дети в Африке не будут голодать и будет рай на Земле. Только не спрашивайте, как это работает, моё дело — рассказать.
2. Ревью через merge-реквесты. Работает вот так:
--- Один разработчик написал код и перевёл его на ревью.
--- Автоматически создаётся отдельная ветка и назначается ревьюер.
--- Ревьюер должен обладать теми же знаниями, что и автор кода. Ну, типа клиентский разработчик не может ревьюить серверного, сишарпер не может ревьюить джаваскриптера и т.д.
--- В этой ветке коллеги обсуждают чистоту архитектуры, а затем ветка мержится в девелоп, и все довольны.
--- Можно организовать сразу через гитлаб, минуя upsourсe, в котором всё делалось до разделения.
Знаете, какой вариант мы выбрали? Никакой!
Код-ревью делается по каждой задаче или ошибке по возможности внутри команды. Если это не возможно, то кросс-командно. Ревью создаётся по коммитам для задачи или ошибки в любой ветке.
Неудобные вопросы после разделения на команды
- Как будет проходить регресс?
--- Ожидание: Все задачи регресса будут равномерно распределяться по командам. Или одна команда делает большую часть, а другие помогают.
--- Реальность: После разделения мы ещё не дошли до регресса, поэтому практического подтверждения нет.
- Кто будет брать случайно найденные ошибки из общего чата?
--- Ожидание: Под индивидуальную ответственность. Нашли, записали, а дальше задачу в работу берёт та команда, которой задача больше нравится. Или в зависимости от загруженности.
--- Реальность: Всё так и работает. До сих пор не было проблем.
- Как будут распределяться дежурства по ТП?
--- Ожидание: Очень просто. Дежурят не команды, а дежурят люди. Если загруженность по ТП большая, можно подключать людей из других команд. Если загруженность небольшая, то дежурные могут совмещать дежурство с повседневными задачами.
--- Реальность: В целом всё так. В крайнем случае особенно большой загруженности можно забить на SLA и решать задачи в комфортном темпе. Но это неправильно и мы так не делаем, конечно же. Честно-честно.
- И как полёт сейчас, спустя месяцы?
--- Ожидание: Никто не ожидал, что команды будут статичными.
--- Реальность: Кто-то ушёл, кто-то пришёл, кто-то перевёлся из соседнего отдела. Бизнес-аналитиков набралось на все команды по одному, как и задумывалось. Но есть некоторый недостаток разработчиков.
Выводы
Короче, разделение на команды — это прикольно и совсем безболезненно. Как ни странно, но после разделения мы узнали друг о друге больше, чем до этого. У каждого даже появилась своя карточка с основной информацией о человеке. Типа любимые занятия, почему он тут и к чему стремится. Очень интересно, обожаю такое.
Новичкам теперь легче влиться в небольшую команду, понять процессы и начать работать. Короче, недостаток людей — плохо, избыток — тоже плохо. Если у вас огромная команда и становится сложно управлять процессами, подумайте о разделении, это реально работает.
А если вам нравится стиль статьи, подписывайтесь на мой телеграм. Если стиль не нравился, всё равно подписывайтесь, вдруг телеграм понравится.
Зол древнее, но на удивление баянометр не показывает дубликаты.
— Наша компания перешла на гибкие методики разработки
— Теперь вы стали эффективнее?
— Да, теперь мы лажаем быстрее
Одна вакансия, два кандидата. Сможете выбрать лучшего? И так пять раз.
Здравствуйте дамы,здравствуйте господа!
Предупреждаю заранее лонгпост!
Это писание расскажет всем,кто только хочет влиться в сферу разработки программного обеспечения и о светлых и о темных сторонах этой сферы,а может и непонятных и даже сложных.
Коротко о себе.Я из СНГ ,веб-разработчик ,веб-дизайнер,C# ,python, и embedded developer.
За последние годы было сделано немало работы в различных направлениях,таких как HMD интерфейсы,различная автоматика и умные решения для дома,в сфере рекламы,голосовых приложениях и много много еще чего.Основное мое направление которое приносит на настоящий момент доход это веб разработка и дизайн.
В общем достаточно предисловий
В свободное время,я как и любой другой человек занимаюсь творчеством.У всех творческий процесс разный.У меня в силу любви к всевозможным техническим решениям это связано опять таки к различного рода разработкам (о которых я возможно расскажу в следующих постах).Естественно обладая желанием (как и любой другой нормальный человек) жить лучше,я пытаюсь привнести в этот мир что-нибудь новое и полезное.Но теперь о стереотипах.
Исторически сложилось так,что непременно на территории всего СНГ считается что разработчики ПО непременно гребут деньги лопатой.Весь вопрос заключается лишь в том,какую лопату вы воображаете,когда мысленно уже гребете деньги.Отчасти таки это так,девелоперы которые в свое время влились в крупную контору(кто по знакомству кто как,вы же понимаете что все что вкусненько делается не без знакомых) или успели уехать за границу по нашим меркам действительно зарабатывают неплохо.Лично для меня неплохо это ОТ 4к$,всё остальное это стандарт.Неплохо зарабатывают и девелоперы умирающих языков,таких как RUBY,все потому,что проект уже существует и разрабатывать с нуля например на node.JS это более объемные вложения,нежели зарплата пусть и дорогая программисту который возьмется за поддержание проекта.Python,GO и прочие варианты сегодня не являются чем то космическим,обучение происходит достаточно быстро lдаж при отсутствии аналитических навыков у индивида.
Вебка - самое востребованное на сегодня на ряду с приложениями.Это и сайты и интернет магазины и веб-приложения типа PWA.Также обладает ценником довольно обычным,но хотябы сопрягается с творчеством.Если чувствуете как выгораете - идите в вебку.Процесс творческий будет явно легче,деньги примерно те же.
В большинстве компания,а особенно западных,непременно существуют различного рода методологии разработки.
Для тех кто в танке вкратце расскажу.
Методологии были разработаны для непосредственно организации процессов разработки.
Мда тавтология однако.
Существует их великое множество однако мы коснемся лишь основных.
Самая лучшая и классная для разработчика но медленная для заказчика пусть и качественная - модель каскадная (Waterfall)
Суть ее в следующем (не понтуюсь выдержка из википедии (гугли: процесс разработки программного обеспечения))
Формирование требований;
Проектирование;
Реализация;
Тестирование;
Внедрение;
Эксплуатация и сопровождение.
Премущества очевидны,ведь всё согласовано и предопределено и задокументировано.
Более того учитывая эту прозрачность,известны как сроки так и стоимость.
Вероятность того,что на вас свалится такое счастье учитывая большинство компаний присутствующих на рынке и список требований заказчика,а крайне мала.
В крупных проектах не встречается однозначно.
Недостатки
Один косяк и откатываться придестя до последней успешной реализации
Не подходит для стартапов
Итеративная разработка.
Суть заключается в выполнении работ с непрерывным анализом
Хорошая тема для стартапов и для проектов с статусом готово.
Позволяет интерактивно вносить правки и получать результат
Все это конечно хорошо,но в основном используется что то другое
.
SCRUM
Тот еще скам.
Не буду сюда пихать википедию а расскажу исходя из своего опыта.
Используется средними компаниями и крупными для достижения результатов малой кровью опять таки со стороны компании.
Работая в такой конторе непременно создается иллюзия единства и братсва,однако на самом деле за этой ширмой идет самая настоящая борьба,
Борьба с собой задачей и командами.
На мой взгляд классный вариант для быстрой реализации MWP (минимально рабочий проект)
Жить в таком режиме на постоянке просто нереально.Это отсутствие размеренной жизни это вечный недосып,это вечные проблемы заказчиков которые должны быть решены первоочередно!
Я работал в таких компаниях но для меня такой вариант на долгострой не подходит.
К слову о деньгах - деньги те же методологии разные.
Выгореть работая по такой методологии обычное дело.И я выгорал.
Если есть возможность не бежать спринты то лучше воздержитесь и ищите другие варианты.
Или же работайте по доске бежите спринт,потом отчеты burndown и всё как выше написано
Я согласился лишь по причине того что на тот момент лучше ничего не было.Чувствуете burnout - бегите!Продукт скорее всего останется дерьмом,а дрючить вас будут постоянно.
Скорее всего вы пока находитесь в этой компании ,вы в этом проекте навечно!
V-Model или Апгрейд каскада
Устранены недостатки касающиеся необходимости отката до успешной реализации
Также все идет своим чередом но включая паралельное тестирование
Использую в своих реализациях для получения действительно хорошего продукта в сочетании с нормальным психологическим здоровьем
XP - экстремальное программирование
Для MWP отличная штука!
Есть идея желание и мысли?Либите сидеть за компом по ночам? То что надо но ненадолго.
Лично я использую данный метод в период инициации проекта.Смотрите - есть идея и видение ее реализации сейчас парочку ночей не посплю зато через несколько дней есть MWP для показа инвесторам
Далее переходим на V-Model и спокойно допиливаем начатое до идеала,потому как единожды что то сделав действительно классно,повторить бывает зачастую сложно и даже невозможно.
Поэтому для меня симбиоз XP + V-Model лучший выбор хотя возможно и странный.
KanBan - хорошая штука на стадии допиливания.
Позволяет учесть все недоработки на пути к релизу и пофиксить их.
Хоть все и делается сумбурно однако процесс прозрачен и цель в отличии от SCRUM определена.
Все доработки выполняются в сочетании с хорошей задокументированностью и методиками позволяющими сократить время,а необходимые стадии фиксируются на доске kanban.
Ну хватит пожалуй методологий и прочей ереси а где хорошо тогда?
На сегодняшний день если вы человек талантливый и умеющий что - нибудь делать,лучший вариант это создание своей фирмы и работа на себя.По началу конечно трудно,но есть гибкость управления своим временем и возможность обрести новые знакомства ,работать совместно с кем-нибудь ну вы поняли,что тут долго говорить.Если вы не обладаете средствами для создания чего-то своего - вам на KickStarter и прочие стартап платформы.Если же идея вас не посетила,ищите команды где вам будет работать в удовольствие.
Программирование на сегодняшний день,если не несет инновации это самая обычная работа как и любая другая,поэтому не стройте иллюзий что вы супер-пупер специалист и по вам плачет Америка.Не плачет и там давно все рассажены по своим местам.Никто там вас ждать не будет.
Да и не только в Америке так,сейчас так везде.Программисты из Индии стоят копейки,имейте это ввиду.