Рубрика «управление проектами» - 111

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

Нужно ли менеджеру уметь программировать - 1

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

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

Обзор TeamLead Conf: 2 дня по 2 трека, 25 докладов, 474 участника, излитая боль неизмерима - 1

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

  1. Нужен ли вообще тимлид?
  2. Что есть тимлид, какие у него задачи?
  3. Что сначала: команда или тимлид?
  4. Необходимы ли тимлиду технический навыки?
  5. Вырастить или нанять?
  6. Как понять, можно ли и нужно ли выращивать из инженера тимлида?
  7. Сколько времени нужно, чтобы вырастить тимлида?
  8. Менеджерские роли тимлида, какая роль предпочтительней?
  9. Насколько важны эмоциональный интеллект и социальные навыки?
  10. Что делать если руководитель сам является техническим специалистом и падок на микроменеджмент?
  11. Тимлид ушел на неопределенное время (отпуск, больничный, форс-мажор), что делать?
  12. Что делать, если тимлид уходит насовсем?
  13. Какое должно быть соотношение менеджмента и разработки в работе тимлида?
  14. Есть ли путь назад (и вперед)?
  15. Какие перспективы карьеры тимлида?
  16. Что может помешать стать тимлидом?
  17. В чем разница между тимлидом и техлидом?
  18. Как выявить неэффективного тимлида на ранней стадии?
  19. Как начинающему тимлиду справиться с потоком информации?
  20. Нужен формальный или неформальный лидер?
  21. Junior и Senior тимлид, в чем различия и как держать их в одной команде?

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

Под катом — обзор лучших докладов TeamLead Conf с видеозаписями и презентациями.
Читать полностью »

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

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

Генеральная уборка в компании: как мы переворошили магазины - 1

Бомжи жили около магазина пару недель. Это прямо выход из метро, поэтому им там было тепло и уютно. Решилось тем, что как только открывалась дверь, сотрудник брал толстые резиновые перчатки, и либо прямо выносил их на улицу, либо вёл с ним беседу по поводу, почему они мешают. Если они успевали полежать хотя бы 2 минуты — это вполне их устраивало. А когда и 10 секунд не давали — ну, направление миграции сместилось.

На деле, конечно, это была меньшая из проблем. И самая легкорешаемая.
Читать полностью »

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

image
Читать полностью »

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

Масштаб

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

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

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

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

Всем привет!

Сегодня у нас на связи Василий Савунов, управляющий партнёр компании ScrumTrek, agile-коуч. Немного поговорим об организации работы команды по системе Scrum, а также получим ценные рекомендации по обучению Scrum и Kanban.
Что нам стоит Scrum построить: интервью с Agile-коучем Василием Савуновым - 1
Читать полностью »

Ученье — свет, или как организовать мастер-класс за 2 дня - 1

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

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

Чем статья может быть полезна вам?

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

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

Не все позиции, представленные на витрине Crossover однозначно понятны потенциальным партнёрам. И если вакансии C++ Software Engineer или Java Software Engineer вопросов не вызывают, то с Chief Software Architect всё не так и просто. Вообще, кто такие архитекторы ПО чёткого определения нет и от компании к компании их функции и описания разнятся. Сферический Software Architect (SA) в вакууме определяет архитектурный шаблон/парадигму, отвечает за разбиение на технические подсистемы/слои/компоненты/модули, выбирает средства исполнения и занимается разработкой технических сценариев. От места к месту функции могут добавляться или исчезать, но в целом работа Software Architect заключается именно в этом.

Из точки А в точку Chief - 1

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

Если вам вдруг показалось, что к этому меню не хватает разве что щепотки менеджмента, то Chief Software Architect (или если сокращенно, то просто CA) — это для вас. Туда входят уже такие ингредиенты, как создание масштабируемых решений, контроль процесса разработки, контроль работы команды и персональная ответственность за результат в целом. Многим хотелось бы знать, откуда такие люди берутся. В случае Crossover: из вагонов метро и магазинов меховых изделий. По крайней мере, если судить по трудовым биографиям двух действующих Chief Software Architect компании Optiva Руслана Пещука и Евгения Конурбаева.
Читать полностью »

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

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

Читать полностью »

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

image
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js