Deep work Как восстановить свое внимание и погрузиться в работу все про пошукову оптимізацію та веб розробку українською.

Не редкость, что в команде из мидлов и джуниоров роль тим лида выполняет милд девелопер. Тим лид — это не рост вверх после синьора, это рост в ширину, это дополнительные обязанности члена команды в разрезе работы с людьми/командой. Привет, я Олег Абрамов, VP of Engineering в продуктовой компании iDeals Solutions.

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

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

QA Fest — конференция, созданная тестировщиками для тестировщиков.

У кого-то их мало и справляються с этой задачей не допив кофе. У кого их много и одной чашки кофе для этого мало. И эти люди уже начинают строить графики https://deveducation.com/ и дашборды для экономии своего времени. А что делать когда ты тестируешь нефункциональность? Когда количество тестироумых функций исчисляеться сотнями?

• СЕО Екатерина Осадчук и команда Indigo Tech Recruiters провели второй ежегодный обзор заработных плат для C-level в IT.
• А тем временем вышла iOS 10, за одну ночь 50% ваших пользователей обновились, и не поддерживать ее теперь просто нельзя…
• В команде важно поддерживать высокий уровень продуктивности, регулярно общаться с членами команды, руководством и клиентами.
• Прикиньте, сколько времени нужно на ее выполнение.
• Заниматься этой проблемой стоит и интересно.

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

IAM.Leader

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

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

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

«Uklon — это маркетплейс не только по заказу авто». О новых и сопутствующих продуктах

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

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

Антипаттерны и запахи в автоматизации тестирования

Управление людьми можно сравнить с прогулкой по тонкому льду — нужно понимать, когда надавить на участника проекта, где проявить эмпатию, а когда стоит попрощаться с сотрудником. Вообще, четкого предела, «где начинается полиция и где кончается Беня», нет. Редко на каком-то проекте работают и PM, и тимлид, и техлид, и архитектор, и ВА. Там, где они все же есть, вероятнее всего, любые трое из этих пятерых могут проделать всю лидскую работу, если хватит здоровья. Во-первых пойди разбери, кто что думает на самом деле (так что приходится уточнять «а что вы имеете ввиду под должностью тимлида?»), а во-вторых для манагерских позиций крайне важен опыт.

Карьерный рост — куда дальше?

Сейчас это — часть Uklon, но ПО для телефонных служб занимается отдельная команда. Дополнительные раунды интервью могут быть в том случае, когда берем специфического специалиста (например, Product Owner’а). После технического интервью может быть этап защиты задания, которое было на предыдущем этапе.

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

Заниматься этой проблемой стоит и интересно. Лидер — это не монарх и не «авторитет» и не диктатор. Там где это есть — суть есть роль «лида» очень быстро скатывается к «насяльника-я-так-сказал-и-если-даже-клиент-не-так-сказал-сам-дурак». Что тоже очень характерно для апологетов «единой проектной команды» замкнутого на единого господина типа «вассал моего вассала не мой вассал».

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

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

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

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