Обложка канала

Analysis Paradisis. Страница 19

9254 @analysis_paradisis
Открыть

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

  • Analysis Paradisis

    Хакатон как ускоренный курс по менеджменту

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

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

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

    — Расстановка приоритетов. У нас было задумано 5 функций в программе и было понимание, как делать каждую, но не было приоритетов, т.к. мы думали, что мы успеем все. В итоге у нас были готовы все функции на 80%, но ни одной по факту пользоваться было нельзя. Если бы мы изначально подумали о том, какой минимальный набор задач надо сделать, мы бы смогли презентовать продукт с минимальным набором функций, но работающий.

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

    — Понимание, что это всего лишь прототип. Большую часть времени ребята потратили на выстраивание правильной и красивой архитектуры (кое-кто под утро даже рефакторил код соседа, потому что он ему не понравился). На самом деле, чтобы сделать MVP (minimum viable product) и доказать, что идея работает и нравится пользователям, не нужно пытаться построить идеальную архитектуру, надо просто быстро сделать прототип.

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

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

  • Analysis Paradisis

    Теория успешных инноваций, Клейтон Кристенсен

    Я хотела написать следующую заметку про книги тогда, когда дочитаю эту книгу. Но я не смогла, хоть мне ее и посоветовал коллега, которого я очень уважаю :) Книга о том, что прорывы в продуктах не случайны, а имеют закономерность: во всех этих случаях создатели думают, 
    для чего покупатели "нанимают" продукт. Иными словами, это книга о Jobs To Be Done.

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

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

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

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

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

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

  • Analysis Paradisis

    Если делать только то, что знаешь - ничему не научишься

    Если говорить про книгу "Гибкое сознание", то мне, наверно, больше всего запомнилась часть про школьников. Когда учитель спрашивает "кто знает …?", обычно поднимают руки отличники, которые на 100% уверены в ответе на вопрос. Они отвечают правильно, учитель доволен, но никто из них не узнал ничего нового. В книге приводился разговор с девочкой-школьницей, которая сказала "я тяну руку всегда, даже когда совсем не уверена в ответе или не знаю, как решать пример - если я ошиблась, меня поправят и научат. Для этого и нужна школа".

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

  • Реклама

  • Analysis Paradisis

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

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

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

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

  • Analysis Paradisis

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

    Продуктовый мобильный аналитик (Senior)

    От вас:
    - Хорошее знание Amplitude, SQL и Python.

    Что делать:
    — Поддерживать спецификацию аналитики.
    — Отвечать на вопросы продукт менеджеров и дизайнеров. Иногда придется залезть в Data Warehouse или Splunk.
    — Обучать всех пользоваться Amplitude.
    — Планировать и проверять a/b тесты.

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

    Системный аналитик в команду мобильного банка (Middle/Senior)

    От вас:
    - знать Postman, SoapUI или их аналоги
    - уметь работать с логами
    - уметь рисовать UML Sequence
    - иметь опыт работы в командах по разработке мобильных приложений (желательно, но не обязательно)
    Не пишу про "знать принципы разработки ПО, умение писать требования понятно и однозначно" - это по умолчанию.

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

    С нас разные плюшки: бесплатная столовая, свой спортзал, хакатоны и разные турниры внутри компании, и еще много всего.
    В Москве находимся на м.Водный стадион, 3 минуты от метро.

    Вопросы и резюме можно в личку - @shenzzzi, я передам HR :)

  • Analysis Paradisis

    Когда стоит эскалировать

    Дни постов про soft skills на Analysis Paradisis :)

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

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

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

    Попробуйте сначала спросить:
    - почему ваш коллега не успевает?
    - как вы можете ему помочь?

    Вопрос "как я могу тебе помочь?" творит волшебные вещи. Ваш коллега понимает, что вам не все равно, и во многих случаях вы действительно можете помочь: помочь написать скрипт, помочь найти нужную страницу ТЗ. Иногда можно помочь чисто по-человечески: например, сходить вниз на ресепшн и забрать его доставку, а у него будут лишние 10 минут, чтобы отдать нужный вам документ.

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

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

    Помните: в 99,9% случаев у ваших коллег есть адекватные причины не успеть или не сделать что-то: не успеть выкатить задачу к релизу, не успеть отправить документ. И работа в команде - это не про "наябедничать на соседа и испортить отношения", а про "помочь соседу, если ему нужна помощь".

  • Analysis Paradisis

    К проблеме, о которой писала выше - про общение с заказчиками и партнерами:

    Недавно на вопрос "По какой логике вы определяете, использовать этот параметр или вот тот?" мне просто скинули кусок php-шного кода со словами "Вот так. Остались вопросы?".
    Это пример, как делать не надо никогда. Надеюсь, что очевидно, почему, но все же:

    Во-первых, ваш собеседник может не уметь читать код (внезапно), особенно если вы не знаете точно, кто он по должности на стороне партнера.

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

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

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

  • Analysis Paradisis

    Хорошая статья про карьеру продакт-менеджера от бывшего CPO в Netflix: Hacking Your Product Management Career.

    В ней про hard и soft skills, про подход к построению карьеры и про его собственный путь - почитайте, особенно интересно про его графики зарплаты, удовлетворенностью работой и чувством делания чего-то важного для мира :)

    Статья на английском.

  • Analysis Paradisis

    Про общение с заказчиками и партнерами

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

    Например, часто случаются такие диалоги:

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

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

    - Коллеги, добрый день. Подскажите, почему на этот запрос мы получаем ошибку такую-то? (пример запроса)
    - Добрый день! Вы забыли передать параметр userId. Вот пример правильного запроса (пример запроса)

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

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

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

    3. Не приводите отсылок к началу переписок: вместо того, чтобы написать "посмотрите документацию, которую мы вам отправили полгода назад" или "см. сообщение от 14 авг. 2000 года", отправьте эту документацию еще раз или продублируйте сообщение.

    4. Пробуйте не просто отвечать "да/нет" на вопросы, а понимать, почему вас об этом спрашивают. Попробуйте отвечать на вопросы чуть шире, чем вас попросили: вместо "да, этот параметр нужен" написать "да, этот параметр нужен, потому что бывают такие случаи, что…" - очень часто в таких объяснениях можно заранее выявить нестандартные случаи.

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

  • Analysis Paradisis

    Про обязательные и необязательные параметры в ТЗ

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

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

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

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

  • Analysis Paradisis

    Кэрол Дуэк, ребята, не Кэтрин. Книга называется "Гибкое сознание". Спасибо заметившим ошибку 🙂

  • Analysis Paradisis

    Гибкое сознание: люди с разными жизненными установками

    Прочитала "Гибкое сознание" Кэтрин Дуэк.
    Книга - бестселлер, ее очень многие рекомендуют к прочтению, 2400 отзывов на амазоне, почти 5 звезд, а это говорит о многом.

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

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

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

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

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

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

    В книге 347 страниц (301 по теме, остальное - рекомендации и благодарности), словосочетание "установка на рост" встречается в том или ином виде 327 раз, а "установка на данность" - 321, т.е это действительно одна тема на протяжении всей книги.

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

  • Analysis Paradisis

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

    1. Wait But Why - блог Тима Урбана, в котором несколько раз в год появляются лонгриды на интересные темы. Например, как выбрать подходящую карьеру, почему в крионике есть смысл, и даже как выбрать имя ребенку. Для каждой статьи Тим проводит свое собственное исследование, что позволяет ему разобрать тему по полочкам, а юморной стиль делает их не скучными для чтения. Говорят, Илон Маск фанат этого блога. Статьи на английском, но достаточно легкочитаемом, если нужен перевод на русский - большинство можно найти в гугле.

    2. Что если? - блог Рэндалла Монро, автора комиксов xkcd, который отвечает на абсурдные вопросы на полном серьезе с точки зрения физики. Например, что будет, если кинуть бейсбольный мяч на 90% от скорости света, или сколько нужно времени, чтобы спуститься на шесте от Луны до Земли. Перевод на русский тут

    3. LessWrong - уже писала о нем, но он так и просится в эту подборку. Это блог со статьями о рациональном мышлении., который ведет Элиезер Юдковский, специалист по ИИ. Перевод на русский тут

    В общем, вместо котиков на ютубе в свободное время лучше почитать статьи оттуда.

  • Analysis Paradisis

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

    Эта концепция называется Jobs To Be Done (JTBT), становится очень популярной сейчас, и Михаил Руденко, который занимается продуктовым маркетингом уже 9 лет, в четверг, 2го августа с 16-00 до 17-30 МСК проведет вебинар с рассказом, что такое JTBT и как правильно эту технику применять.

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

    Регистрация на вебинар здесь

  • Analysis Paradisis

    Карго культ в IT

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

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

    Грузы, естественно, не появлялись. Вместо того, чтобы остановиться, островитяне начинали молиться самолетам еще упорнее.

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

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

  • Реклама

  • Analysis Paradisis

    О единой терминологии

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

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

    То же самое с продуктом: если заказчик подразумевает под "вывести сумму" вывести сумму с учетом налога, а вы - без, и никто не установил единое понимание слова "сумма" заранее, то на выходе будут проблемы.

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

    Пример с той же суммой: В протоколе одного сервиса у вас есть параметры sum и sumWithTaxes, в протоколе другого - sum и sumWithoutTaxes. С огромной вероятностью в какой-то момент в процессе интеграции между сервисами разработчик/аналитик установит аналогию sum=sum, а не sum=sumWithoutTaxes. С такой же огромной вероятностью аналитик, работающий с командой первого сервиса, придя с вопросом "проверьте сумму" ко второй команде, получит не ту информацию, которая была нужна.

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

  • Analysis Paradisis

    По поводу ТЗ пришли два замечания:

    Не приводить примеры в ТЗ

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

    Особенно относится это к формулам сложнее, чем "2+2", алгоритмам и сложным условиям if-else.

    Неграмотность в ТЗ

    Могу только сказать свое мнение на этот счет:

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

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

    У меня, к примеру, был сотрудник, который писал "Тебе" с большой буквы, потому что считал это уважением к собеседнику, и никак не хотел от этого отказываться :)

  • Analysis Paradisis

    Еще раз про разграничение обязанностей

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

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

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

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

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