Pull to refresh

Comments 11

Я делал чеклист похожий. И даже написал здесь статью https://habr.com/ru/articles/690212/, у меня больше про технологии, у вас больше про людей. Рад найти родственную душу.

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

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

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

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

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

Все ожидания вашего руководителя очень советую выписать отдельно.

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

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

Я бы не советовал протоколировать в стиле "если вы потом забудете, я вам напомню" - это негативно, а я сторонник позиции be positive, don't be negative. Я записываю всегда со словами: "я могу чтото забыть, важное всегда записываю"

 Я записываю всегда со словами: "я могу чтото забыть, важное всегда записываю"

Я и не предлагал записывать со злобным лицом, и требовать прочитать и подписать))

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

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

да, тут согласен. фиксация договоренностей хороший элемент :)

Можно вынести размерности в переменную. И потом заменить "недели" на "месяцы" или "годы" для больших проектов ;)

Цель статьи - показать самый быстрый способ "вьехать" в почти любой IT проект. Почти - ну потому что у меня максимум было 70-100 чел.

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

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

Sign up to leave a comment.

Articles