В свое последней статье «Куча г. не станет золотом» по ходу обсуждения с ZaQ всплыла одна из больных тем – должности/роли/ответственности. Причем больная эта тема не только относительно IT, но и для любого молодого бизнеса.
Может эта проблема есть и для устаканившихся бизнесов, но, честно говоря, сам я ее не видел и бороться не приходилось, так что опустим эту часть.
Я уже задевал эту тему в статье «О разделении обязанностей между технарями и продавцами«, но тут копнуcь слегка глубже.
Проблема с должностями, собственно, состоит из нескольких частей
— люди делают не то, что они должны делать (и мешают этим жить другим)
— люди не делают то, что они должны делать (и из-за этого, что-то идет не гладко)
— люди неправильно распределяют время между несколькими вещами которые они должны делать.
Кстати, везде, где дальше я говорю должность, я имею в виду круг обязанностей, а не то как там называют человека. Я вообще считаю, что «хоть горшком назови, главное в печь не сади». Гораздо важнее, что человек делает и сколько ему платят, чем все эти титулы, которые сейчас не стоят и выеденного яйца.
Итак, с одной стороны проблема кажется надуманной (особенно для тех, кто с ней не сталкивался) и вроде решение лежит на поверхности «ну блин, сказать людям один раз, чем они должны занимать, а если они не вкуривают, то под зад их пинком». Но тут есть множество подводных камней:
— Люди приходят и уходят из компании и то, что вы сказали кому-то год назад новые люди не знают.
— Память человеческая склонна все забывать, особенно, если в нее каждый день впихивать много нового. Кстати, как люди забывают, что вы говорили, так и вы забываете, что же точно вы говорили этим людям.
— Ситуация в компании меняется, и сказанное раньше может не только не помогать, но и вредить и нужно говорить что-то заново.
В общем, предыдущая идея постепенно конвертируется в общение с каждым приходящим о том, что он должен делать (это чаще всего и так делается), общение с людьми у которых меняются обязанности/должности, общение со всеми, когда меняется политика партии. И уже получается, что директор выполняет ни директорскую работу, а только и бегает по офису и втолковывает, кто и что должен делать.
Особенно актуальна эта проблема, для, пока маленьких активно растущих компаний. Несколько раз я видел управленческие кризисы, когда действительно директор только и бегал, для того, чтобы разгрести и раздать обязанности и вспомнить с кого за что он должен спрашивать.
Итак, мое видение решения этой проблемы. С дня номер ноль, когда вы решаете, что вы собираетесь развивать компанию и в ней станет больше народу нужно ввести три вещи:
— структуру компании, к которой вы стремитесь. То есть не ту структуру, которая есть сейчас, а ту которую вы хотите построить скажем через пару лет. Например, генеральный директор, которому подчиняются технический директор, финансовый директор и директор по продажам. Им в свою очередь подчиняются разные менеджеры админы и т.п.
Естественное, если вы, пока один в компании, то лучше разрисовать схему небольшой фирмы, чем схему Microsoft. Например, НЕ нужно отдельного отдела технического поддержки в которой будут менеджеры админов, которым будет подчиняться админы и т.п. Вероятнее всего у вас будет всего один амин в течение следующих пару лет.
— вторая вещь, которую нужно сделать, это для каждой должности буквально в пару строк расписать, что человек с этой должностью должен делать и за что отвечать. Например: “Менеджер по продажам отвечает за общение с заказчиками, заключение сделок, сбор пожеланий и проблем и коммуникацию с директором по продажам и техническим менеджером относительно технических вопросов». Это всего лишь пример, в вашей организации вы вполне можете сказать, что он должен отвечать за доставки пива в офис и за контроль наличия туалетной бумаги.
— третья вещь, которую нужно сделать – это написать для каждой должности, кто за нее отвечает. Не беспокойтесь, в начале это может выглядеть примерно так: “Директор – я, Менеджер – я, Программист – тоже я». Собственно, так реально дела и обстоят, когда вы один в фирме.
Что же теперь делать с этой все фигней, которую вы написали?
Во первых, когда вы наняли нового человека, вы можете списать с себя или с другого одну или несколько из должностей на него. Когда кто-то уходит, вам наоборот надо забрать все должности с уходящего человека и распределить между остальными. Так же вы можете перекидывать с одного на другого должности. И когда происходят кардинальные изменения, то менять всю схему по вашему новому видению или менять требования к какой-то из должностей.
Вообще, не бойтесь менять эту схему, она не высечена в камне. Как раз основная идея, подстраивать ее под ситуацию.
Естественно, в тот момент, когда вы что-то меняете – то нужно оповещать людей, на которых это повлияло. И само собой, это схема должна быть доступна для всех и не является супер-секретным документом по захвату галактики.
Теперь следующий вопрос, зачем столько пурги, вокруг этого вопроса? Как обычно, можно сказать: «очередное бумагомарательство и так все умные люди и все знают, что делать».
Искренне надеюсь, что с вами работают только умные люди. Но, как я писал, проблема состоит в том, что все постоянно меняется и вы сам в том числе не всегда способны уследить, за продажу отвечает Вася (новый директор по финансам, который был директором по продажам) или Петя (новый менеджер по продажам)?
Как вы понимаете, это действительно критично, кто за что отвечает, чья обязанность что-то делать и в конце концов, и если что-то не работает то с кем надо общаться. Если ошибка в коде, может вылиться в немножко потерянной прибыли, то ошибки типа, «ой… а у нас оказывается никто не отвечает за общение с клиентами» (шутка, конечно, но бывает близко к реальности) чревата гигантскими потерями.
Кстати, опять же эта проблема, очень болезненна для партнеров. Чаще всего при старте бизнеса, партнеры не распределяют между собой должности таким образом или распределяют их очень примерно и в результате получается, что что-то делается два раза, а что-то не одного.
Ну и еще одно, последнее дополнение, это то, что те, на ком висят больше одной должности, должны знать, сколько времени они должны на каждую из них, чтобы не получалось, что они будут ущемлять одну должность, ради другой.
P.S. Особенно эта вся фигня помогает преодолеть проблемы 10-20 человековой компании, когда компания становится слишком большой, чтобы директор во всем участвовал, но еще достаточно маленькой для серьезного распределения по отделам, должностям и т.п.
Мысль очень здравая, только обычно директора (или манагеры) прячут такого рода схемы. Почему не понятно. На вопросы типа «А кто здесь за что отвечает? Почему у нас нет того-то и того-то в срок?» говорится, что не ваше это дело знать такого рода вещи, идите лучше код писать.
Ну дык для того и прячут, чтобы никто кроме манагеров не знал, что с этих манагеров можно спрашивать. Ато кодеры обнаглеют, права начнут качать и т.д. Кому из начальства такое нужно?
А статья понравилась. Да и вообще этот блог в моем рейтинге источников информации сразу после dzone.com 🙂
>А статья понравилась. Да и вообще этот блог в моем рейтинге источников информации сразу после dzone.com 🙂
Спасибо тезка 🙂 Очень приятно.
P.S. Пошел разбираться, что там за dzone.com, чтобы рейтинг мне не портили :))
Ну, я в основном конечно говорил с точки зрения владения фирмы. Но я согласен, в фирме особенно небольшой должна быть достаточно прозрачная структура.
И кстати, это потрясающе, когда исполнитель не боится пойти к менеджерам и сказать, блин, кто за это отвечает. Оно не работает и мне из-за этого сложно делать свою работу.
Отлично!
Разве что нужно добавить, что описанная деятельность называется «HRM» (обрезанный отечественный аналог звучит как «Управление персоналом»), а его должность/роль звучит как «Менеджер по персоналу». И эту должность необходимо сразу и безусловно учесть в структуре компании 🙂
Безусловно.
Либо эту должность нужно учесть, либо выдать какой-то другой должности обязанности эквивалентные менеджеру по персоналу.
боюсь что это несколько выходит за рамки HRM, хотя HR менеджер хорошей квалификации должен разбираться в азах 🙂
это что-то ближе к Organizational development.
http://en.wikipedia.org/wiki/Organizational_development
Ну и вторая по очереди, но первая посетившая меня мысль звучит так:
«Как вы лодку назовете, так она и поплывет» — и это противоречие народного фольклора с не менее народным «горшком» необходимо всегда помнить.
А именно:
а) если уже в окружающем нас мире существует правило применения определенного и (что самое главное) точного и непротиворечивого именования какого-то понятия, это правило необходимо выполнять. Называйте «лодки» своими именами 🙂
б) если правила нет, или есть в данном конкретном случае много противоречий — то называть можно хоть «горшком», если это не нарушает права этого самого горшка (не садит его в печь).
Так что в случае с «менеджером» я бы не стал выбирать вариант б) (по сугубо личным ощущениям справедливости и чувства прекрасного 🙂 ), а в случае с компанией от 20 сотрудников и больше — не советовал бы вообще поддерживать существование хоть одного «горшка» в документах и «традициях» компании.
Честно говоря, в последнее время меня немножко утомили эти титулы. Люди ставят себе любые титуты. Человек сделал сайт и назвал себя CEO компании (при том, что компания еще и копейки не принесла).
Или например в небольшой компании (на человек 15), кого-нибудь называют VP of marketing. И у этого VP нету не подчиненных, ни собственного стола, за которым сидеть и он постоянно садиться на место отсутствующих программистов и т.п.
А в другой компании, на team lead’е висит — общение с заказчиками, выбор функциональности, которая пойдет в следующей релиз, общение с sales и т.п.
Поэтому, меня гораздо больше интересуют именно обязанности, а не титулы.
В том-то и проблема, что правило наименование есть, только используют его неправильно.
Это главная проблема быстрорастущих компаний, когда вроде бы и дело делается, но времени на сон уже мало 🙂
Кстати, часто такие схемы есть в каждой организации, но более серьезной документации нет. Ограничиваются списком «Директор — я, Менеджер — я, Программист -Вася». Что делает менеджер, программист и директор зависит от настроения и фазы луны. Должностные инструкции есть номинально на совковых времен и реальной картины не отражают.
на родственную тему, кстати, на местном блоге отписался 🙂
Да, по большему счету схемы должны быть четыре
а) Схема должностей
б) Схема соответствия обязанностей каждой должности
в) Схема какая должность кем заполнена
г) Схема сколько процентов человек должен тратить на какую из своих должностей
Как только одна из схем пропадает, то остальные имеют очень мало смысла.
Кстати, а что за родственная тема?
Вот с пунктом Г) я не соглашусь, точнее схему то сделать можно, но вот расставить приоритеты не по должностям, а по задачам решаемым в каждой конкретной должности.
В реальности очень тяжело брать на себя обязанности нескольких должностей полностью.
Например сэйлз и технический ПМ в одном человеке сочетаются с трудом, скорее такое совмещение невозможно, а вот взять на себя отдельные задачи можно. Единицы могут беспрепятственно совмещать в себе две эти должности, противоречивые зачастую.
Вся система из абвг довольна громоздкая и неповоротливая, я бы такую придушил (вот такой я жестокий 🙂 ), а вместо нее внедрил бы попроще, но обязательно формализовал бы :))
>Кстати, а что за родственная тема?
Разделение обязанностей и ответственности в проекте.
dndev.org.ua
Я бы не сказал, что она такая уж громоздкая.
Та схема, которую вы предлагаете — потребует определения списка обязанностей конкретно для каждого человека. Это все таки более детализовано, чем список для должностей.
А насчет совмещения сейлс и технический ПМ. Ну ok, плохо совмещаются, так не совмещать их.
Комент к постскриптуму. Это не менее важно в компаниях 10-20 когда прибыли еще не на столько велики, чтобы допускать простой хотя бы 2-3 сотрудников :). Когда в конторе человек 200 и даже когда все 200 будут пару месяц не работать, то контора не загнется, то директоры и HMR становятся почему то пренебрежительны к своим обязанностям и перестают даже бегать и объяснять обязанности (не говоря уже о какой-то документации 🙂 ). Или даже не так… Пока контора была 20-40 человек, был директор который «бегал». Контора выросла, директор перестал успевать бегать.. Его уволили или перевели на другую должность и взяли другого опытного директора, который правильно понимая, что в такой крупной конторе не его работа «бегать», но при этом он тоже не понимает необходимость описания должностных инструкций… Кстати, применительно к одной компании в которой я работаю, я о необходимости четкого описания инструкций своему начальнику говорил не раз. А потом когда его заменили группой специалистов пришедшей из другой развалившейся компании, я и этой группе специалистов говорил тоже самое 🙂 Но они меня с моими советами задвинули заниматься своими делами 🙂
Кстати, для той должности, которую я занимал и для своих подчиненных я описывал список дел, за которые мы отвечаем и вывешивал во всеобщий доступ (не сразу правда до этого додумался, а после пары неприятных инцидентов), таким образом у меня как правило в последние два с половиной года работы не возникало ни с кем проблем, по поводу того, что не работает по моей вине, а что не по моей. Отсутсвие такого рода споров позволяет в хорошем настроении работать над устранением неполадок больше времени, а не тратить его (время) на лишний разборки.
А вообще статься очень полезная. До того как я ее прочел, вроде все описанное в ней прекрасно понимал, но ни разу не формулировал достаточно четко ни для себя, ни тем более для кого-то другого. 🙂
Да, интересная вещь, что инициативой снизу, такую схему очень тяжело продвинуть. Это может идти только сверху. Эта та самая ситуация, которую ты описал, что совет не пригодился.
Проблема просто в том, что людям чаще удобно просто бегать и они могут даже бояться, что если они бегать перестанут, то они станут не нужны.
>что если они бегать перестанут, то они станут не нужны.
забавный случай произошел недавно, как мне кажется, на похожую
Мимо проходящий начальник (VP и т.д., по-русски не разговаривает, иностранец, опытный вообщем) заметил что зашел на форум велосипеднsq (хобби). Подошел, кивнул головой в экран и спросил «What’s up?».
При том что на проекте все хорошо, нет аврала, все идет по графику, все знают чем заниматься, вообщем больше недели я минимум времени на проект трачу, даже скучать начал. Что это был за вопрос, я понимаю с трудом, собственно и что ответить я толком не знал. Может объяснит кто менталитет американского ПМа? Или где я не прав?
PS. Про то, что на работе должны «вjobывать» в курсе. (более подходящее слово тяжело подобрать 🙂 )
Кто ж тебя знает. Тут одно из двух. Либо у вас на проекте на самом деле все не так хорошо как хотелось бы манагеру, а ты просто этого не знаешь. Либо манагеру просто нада показать свою крутость. Но решение в обоих случаях одинаковой. Спросить его, что ему не нравится. 🙂
ответить стоило бы шо нить типа «nothing. what do you mean?» 🙂
я примерно это ответил 🙂 но внятного ответа не получил.
Он вообще не в курсе что у меня с проектом, он VP соседнего отдела.
что-то меня не туда потянуло 🙂
Я просто неоднократно встречал/слышал такое именно от американцев 🙂
Возможно он думает что комапания зря оплачивает мое время, которое я на форуме провожу? 🙂
Интерсно узнать есть ли какие шаблоны поведения в американской школе менеджмента подобного этому?
Ну, вообще What’s up, могло быть и просто приветствие :)))
А так, бывают конечно люди, которые считают, что контроль чужих экранов их прямая обязанность.
Судя по описанию ситуации, это было что-то вроде: «Че тут у тебя интересненького?». Скорее всего, доброжелательно, но если он сейлз, то наверняка сделал себе галочку на будущее, и если не дай бог возникнет проблема, запросто может этой какашкой метнуться. Это они любят 🙂 А вообще я заметил, что если люди не понимают технологического процесса, а особенно менеджеры не понимают, чем они вообще руководят… точнее даже так: иногда они от скуки или хз от чего пытаются поруководить тем, куда им лезть совсем не надо. Вот тут начинается самый цирк. У меня в Штатах был случай, когда CTO компании мне сказал, что к нему заходил VP of Business Development (который мне как-то прямым текстом сказал, что он ни хрена не понимает, что я вообще делаю) и сообщил, что каждый час-полтора он видит, как я выхожу из офиса покурить. По его подсчетам, это обходится компании в 3-4 часа потерянного времени еженедельно. На моё ленивое замечание, что я вообще думаю, пока курю, мне сообщили, что по мнению того же VP of Business Dev, внимание… программисты должны думать возле компа. 🙂 Таким образом, кстати, можно сделать еще одну оговорку: кроме наличия схем, любом менеджеру неплохо было бы понимать хотя бы основные принципы предметной области, в которой ты работаешь, даже если твои прямые обязанности с этим не связаны. Этот VP of BD до этого работал одним из VP в Manpower, и судя по его фазенде и образу жизни, работал весьма успешно. Но в IT это пожалуй самый бесполезный человек, с которым я когда либо сталкивался.
И только что пришла еще одна мысль: самый главный менеджер должен контролировать работу и вице-президентов, а не относиться к ним особо благодушно по причине высокой должности. Чтобы не было вот такого раздолбайства. Увы, это тоже часто бывает не так.
Да, какашки они любят в карманах хранить 😉 Тихие и добрые до тех пор пока вдруг, не нужно кого-нибудь забить ногами.
Кстати, это серьезное отличие от того, как у нас ведут себя. У нас сразу показывают в фаворе человек или нет. И это тонкое различие нужно учитывать, если работать с штатовскими.
Пр поводу описанной ситуации с VP. У меня по этому поводу есть мнение, что
а) Даже самый высший менеджмент, должен иметь отчетность и выполнять свои обязанности, а не шляться и считать кто, что курит.
б) Никто не должен иметь право «прыгнуть» через голову чужого менеджера и выговаривать его подчиненному.Кстати, не только выговаривать, но и давать задачи.
По поводу б) у меня были кое какие трения с одним VP, который все любил подкинуть чего-нибудь интересненькое, пока прямой менеджер не видел 🙂
Собственно, я его плохо знаю, чтоб делать какие либо выводы, поживем -увидим.
Возжомно да, интересовался, я не знаток английского, такую фразу воспринял в прямом переводе. Надеюсь думать за MS Project’ом не будет заставлять 🙂
Вот языковой барьер в действии.
а) здесь начинается темное царство топ-менеджмента
б) Как показывает опыт настройки процесса разработки в компании, люди любят через голову задачи выдавать, пока не сделают запрос на ресурс как надо и не согласуют, человека с проекта не отвлекали. Чуть до слез не доходило.
от у меня, как подчиненного с этим б) никогда проблем не было. Я всегда старался узнавать у директора, кто мой непосредственный начальник. И если кто-то что-то просил меня сделать быстрее, чем то что я уже делаю или уж, тем более, что-то не входящее в мои обязанности, я всегда прямым текстом посылал этого кого-то к моему начальнику не взирая на должности и звания этого кого-то. 🙂
В среди девелоперов много вчерашних студентов, некоторым может смелости не хватить, еще есть вариант, когда в компании этим никто раньше не заморачивался, а штат вырос с 10 человек до 80 за год.
Лечение от такой болезни компании тяжелое получается, некоторые упорно едят кактус.
Кстати полезно инструктировать каждого в команде, что без «благословления» менеджера текущего проекта переключаться на другие задачи нельзя.
>еще есть вариант, когда в компании этим никто раньше не >заморачивался, а штат вырос с 10 человек до 80 за год.
Мне кажется — это основная проблема.
Так как к студентам напрямую никто не пристает, если в компании уже отучили всех это делать.
Да, согласен. Чужой язык и чужая страна — это серьезные барьеры.
Насчет б). Да, пока не привьется культура делать через начальников, то делают напрямую. Чаще всего это как раз проbcходит, так как фирма была маленькая и все делали раньше напрямую.
Кстати, формулировки этого я из какой-то книги нагло сдер, но и какой не помню.
Кстати, сейчас у нас построили таки систему без четкого описания инструкций, но строго иерархическую. Теперь директор «бегает» тока к 4-5 человекам, те каждый в свою очередь уже сами распеределяют свои обязанности по еще 4-5 человекам («бегает» по ним), каждый из которых в свою очередь тоже «бегает»… Правда мне не кажется такая схема достаточно эффективной. Т.к. управленческий аппарат по размерам сопоставим с производственными мощностями. Но оно хотя бы работает 🙂 И я подозреваю шо по подобной схеме у нас работают 99% предприятий и организаций в стране 🙂
Какая-то схема лучше ее полного отсутствия. Но, все таки, в описанной тобой схеме есть элемент испорченного телефона.
Он бежит, к подчиненному, тот бежит к своему подчинненному, тот в свою очередь к своему. Как результат мысль доходит сильно искаженной и на одном и том же уровне (программисты) в разных ветвях могут оказаться наделены разными уровнями обязанностей, что есть странно.
В ней еще куча недостатков. Ее преимущество — это отсутствие неоюходимости для начальника совершенствовать свою систему :). Т.к. она коек как работает, а в случае неудовлетворительной работы какого-то отдела/направления его можно уволить того из 4-5 кого ты назначил ответственным за него, взять на его место другого, тот в свою очередь выберет из имеющегося персонала тех, кто ему понравится остальных разгонит и возьмет на свое место других. Собственно подобная схема не нова, не совершенна, тем не менее она рабочая и применяется всегда когда отсутсвует другая. Наверное это первое, что приходит любому директору в голову, если он не знает с чего начинать. Вопрос в том, пойдет ли он дальше? 🙂 Станет ли менять схему организации? 🙂
Да, я понимаю. Это минимальная работающая схема.
Хорошо, что работающая. Плохо, как она работает.
Замечу, что конечно схемы и тд это очень хорошо, но не надо забывать что бумага все стерпит 🙂
Просто написать кто чем занимается и кто за что обязан, это только 10% всего дела — важен не столько закон, сколько его исполнение. Поетому большая ошибка думать что бумага будет за вас работать (почему-то многие об этом забывают), тоесть расписал один раз, пару раз подправил по обстоятельсвам, а все остальное будет работать и без вашего ведома. Должна быть прежде всего система исполнения! Надо постоянно следить, помогать, учить, напоминать, чтоб то что вы нарисовали на листике работало и давало позитивные результаты. Надо все держать в своих руках, только тогда будет толк, а когда отгородиться листиком с обязанностями, то обычно это заканчиватеся развалом фирмы.
Для этого существует QA отдел (как кто-то раньше замечал не QC, а именно QA), который регулярно чекает, что бы все все делали по инструкции. В маленькой конторе его обязанности естественно исполняет сам директор. 🙂 Или не исполняет, тогда все плохо 🙂
Я думаю не всегда даже нужно, чтобы это проверяли (особенно в маленьких фирмах). Просто обязанности должны быть таковыми, чтобы зачастую проблемы всплывали сами.
Если есть какая-то обязанность, которая не дает никакого ответа. В смысле ее можно делать или не делать и никто это не заметит. То, что-то неправильно в этом обязанности.
Эээ… Дык заметят, только поздно будет. 🙂 А мы ведь как труъ директоры не хотим, чтобы проблемы выявлялись позно? Тем более такой отдел нужен не для маленькой фирмы (в маленькой и сам директор все заметит), а для такой, в которой сам директор может ничего и не заметить, а полагаться, что девелопер, заметивший, что сэйлз или тестер что-то делает ли не делает не по инструкции, и побежит об этом сразу докладывать, конечно можно…. Но я бы не стал 🙂
Имхо, такие вопросы должны решать менеджеры. Разработчиков или тестеров в это лучше не ввязывать.
А так да, что касается меня и моих проектов — несчадно указываю на отступления от процедуры. через пару месяцев уже сами соблюдают как надо и мой ошибки вскрывают.
Оздоровительный эффект на лицах менеджеров видно сразу 🙂
Скажем так, инициатива снизу хороша. Но нужно, чтобы у этой инициативы были рамки.
Что мне очень не понравиться, если прибежит тестер и скажет… А вы знаете, что VP играет в Doom вместо того, что работать.
а) Это не конструктивно
б) Возможно VP уже сделал работу на 4 дня вперед
в) Просто терпеть не могу такое «капание»
Если же тот же тестер прийдет и скажет.
Я уже две недели пытаюсь выбить у VP документ в котором описано то-то и то-то и он не дает ни мне, ни моему менеджеру, а у меня из-за этого работа простаивает и заказчик уже начал жаловаться.
Вот тогда уже можно идти к VP и выяснять в чем проблема.
абв — все правильно, работу нужно оценивать по результату, а не по тому, сколько кто чем занимается. а «стукачество» не приветствую.
>…ни моему менеджеру…
Вот на этом этапе именно Менеджер, а не тестер должен идти и выяснять в чем проблема. Если же тестер ходит, то звено «Менеджер» в компании лишнее, но тогда броуновское движение появится. Или Менеджера в печь.
Да, согласен, я погорячился. Тут действительно должен идти менеджер.
А вот если и менеджер не хочет и дуплиться, то вот тогда должен идти тестер и говорить, что тормозят и VP и менеджер.
Хотя, такие вещи проще написать, чем сделать. Большинство людей очень боятся таких вещей, так как отношения это с менеджерами не улучшает.
Это уже искуство правильно излагать свои мысли. Не каждый тестер это умеет. 🙂 Во-первых в любом случае если тестеру чем то мешает работать, что VP «думает», то он сначала должен сообщить об этому самому VP, и только когда VP его проигнорирует (что обычно происходит крайне редко. Чаще просто тестер сцыт сказать VP чтоб тот шел шпилить на улицу 🙂 и не мешал работать, а вместо этого терипит и теряет в производительности) вот тогда уже сообщать начальнику VP. 🙂
И ваще. как тестер может шо то знать чем занимается VP? ^) у VP должен быть свой кабинет 🙂
Конечно кабинет очень желателен, но для маленьких компаний это часто невыполнимо.
Ну и плюс, кабинет должен быть для того, чтобы можно было проводить совещания, так что бы другие не тревожили и то, что является конфиденциальным.
Но, явно кабинет должен быть не для того, чтобы тестер не мог видеть, чем занимается VP.
Наш VP (он пару проектов ведет) отказался от отдельного кабинета, а сидит вместе с разработчиками. И сделал правильно, имхо.
Да, естественная, когда кто-то мешает работать правильная последовательность
а) Поговорить с мешающим
б) Поговорить с своим менеджером
в) Поговорить с менеджером мешающего
Насчет того, что люди плохо умеют излагать мысль. Пусть тренируются.
В конце концов — если умение излагать требуется для нормального выполнения работы, значит таки этому надо научиться.
Все как обычно упирается в цену вопроса. Вводить целый отдел, например для того, чтобы на 3 дня раньше выявить, что что-то неделается. С одной стороны можно, с другой нужно считать выигрыши и затраты.
Я бы не сказал, что это 10% дела. Проблема в том, что обычно закон никто не пишет.
Когда закон не написан, то хоть все до безумия исполнительные, все равно будет «дикий запад». Очень быстро люди привыкают к тому, что закона нет, а соотвественно можно получить по шапке не за что и так же могут похвалить не за что.
Да, естественно, нужно следить, за тем, чтобы закон исполнялся. Но закон в этом смысле первичен, а исполнение вторично.