Далее привожу все найденные мной факторы, которые привели меня к столь неприятному положению дел.
Недоверие
Какой самый простой способ разгрузить себя? Конечно делегировать часть обязанностей кому-то другому. Но, покуда ты не доверяешь членам своей команды, ты не можешь этого сделать. Как можно передать ответственную функцию человеку, которому ты не доверяешь? Ведь тогда ты не будешь уверен в результате. Я думаю подобного рода проблема обыденна для руководителей вышедших из рядовых сотрудников. Они думают, что кроме них никто больше не сможет сделать дело так же хорошо и потому не могут довериться даже самым ответственным, что уж говорить о безответственных. Что приводит к увеличению нагрузки самого руководителя.
Итак, чтобы делегировать обязанности, необходимо доверять своей команде. А чтобы доверять своей команде, необходимо серьезно отнестись к её формированию и организации процессов.
Выводы:
- При формировании команды необходимо иметь ввиду, что часть сотрудников будет принимать ответственные решения и им нужно будет дать свободу действий. Поэтому при найме нужно уделить внимание кандидатом, готовым брать на себя ответственность и проявлять инициативу.
- Давать свободу принимать решения ключевым кадрам.
- Наладить самоорганизацию. Инструменты самоорганизации можно взять из того же scrum-а: планирование спринта, подготовка к планированию спринта, ежедневные планёрки и, самое главное, ретроспектива. Данные инструменты позволят сделать процесс разработки более прозрачным и обнаружить проблемы и ошибки раньше.
Перечисленные меры позволят снизить загрузку руководителя, позволят ему взглянуть на процесс разработки со стороны и заняться своей основной обязанностью — организацией работ.
Полномочия на подбор кадров
Было бы очень хорошо нанять правильных людей в правильном количестве причем прямо сейчас. Но полномочий для замены некоторых сотрудников выставленных инвестором может и не быть. А понимание необходимости замены может не быть настолько ясным чтобы настаивать перед инвестором.
Выводы:
- Полномочия обсуждаются до начала проекта, чтобы в дальнейшей не возникло патовых ситуаций.
- Даже когда официальных полномочий не хватает, всегда можно попытаться убедить, но для этого необходимо уметь вести переговоры. А это умение получается довольно долго и мучительно.
Уместные кадры — залог эффективного распределения обязанностей в команде.
Микроменеджмент
Отсутствие необходимых кадров и недоверие рождает микроменеджмент. Ты, как ответственный, но неопытный руководитель, пытаешься заглянуть через плечо каждому сотруднику и проконтролировать его работу, а иногда и сказать как именно он должен делать свою работу. Таким образом складывается очень неблагоприятная ситуация в команде: работники начинают считать руководителя последним засранцем, сующим свой нос куда ему не следует, и перестают брать на себя ответственность окончательно. Гораздо лучший подход заключается в самостоятельном выборе пути ключевыми сотрудниками, при условии что они понимают миссию и ближайшую цель.
Выводы:
- Дайте команде миссию, видение проекта и ближайшую цель. Гораздо проще объяснить куда мы идём, чем управлять походкой каждого. К тому же это порождает доверительные отношения в команде, если конечно применяются инструменты для самоорганизации команды и перекрёстного контроля вроде scrum-а.
- Ближайшая цель должна быть SMART. Только в этом случае ей можно будет руководствоваться каждый день, определять какие задачи соответствуют ей, а какие нет.
Несфокусированность
Про цели стоит сказать дополнительно. Мало кто пользуется SMART целями в формировании требований к программному продукту. Часто формирование требований начинается с самого конца — непосредственно с требований. К примеру, есть требование сделать журнал записи на платные услуги. Можно сделать календарь с выбором дат, отображением свободного и занятого времени, возможностью сделать произвольное количество записей в одно и то же время т.к. одновременно могут вести приём несколько специалистов, подтверждением записи специалистом, указанием перечня услуг, возможностью изменить перечень услуг после записи и т.д. И получить достойный функционал записи на приём, который можно использовать почти во всех мыслимых случаях! Но стоит ли создавать этот непростой функционал, если цель — создать простейшую запись на приём специалистов ведущих индивидуальный приём и оказывающих только одну услугу? В этом случае достаточно календаря с датами и возможностью выбрать время с настраиваемым шагом записи и настраиваемой длительностью приёма. Явно и точно сформулированная цель способна избавить вас от лишних трат сил.
Но есть и другая проблема рождаемая отсутствием сформулированной цели — это стремление достигнуть сразу нескольких несформулированных целей. А цели лучше достигать по очереди. Приведу аналогию из игр-стратегий: сначала создается поток ресурсов (золото, кристаллы), затем начинается постройка армии. Если же сначала построить барак, то у вас не будет ни денег ни армии. Сначала стоит добиться одной цели, а результаты её достижения положить в фундамент для достижения следущей.
Выводы:
- Сформулированная SMART цель позволит вам избежать ненужной работы.
- Цели стоит достигать по очереди. Для ясности отдалённого будущего можно создать дерево целей, где в корне лежит, к примеру, ваша миссия или глобальная цель, а листьями являются SMART цели.
Отсутствие обучения
В результате вышеизложенных проблем мы приходим к ситуации, когда текущая работа полностью вас поглощает и не даёт вам взглянуть на ваши действия со стороны. Вы повторяете свои действия снова и снова и единственный выход, который вы видите — делать всё то же самое только БОЛЬШЕ и УСЕРДНЕЕ. Вы уже не отдаёте себе отчёт в том, что именно повторение заученных действий является причиной текущего положения дел. И для того чтобы изменить текущее положение дел, необходимо начать действовать по-другому.
Выводы:
- Даже в сложные времена, необходимо учиться. К примеру, выделять час рабочего времени на чтение книг — это позволит вам увидеть новые более перспективные модели управления.
- Проводить ретроспективы. Данное мероприятие позволяет учиться целой команде за относительно небольшую цену. Но есть нюанс — качественной ретроспективы, где люди говорят о действительных проблемах и не боятся высказывать свои мысли, можно добиться только в условиях психологической защищенности, где каждый уважает каждого несмотря на возможные разногласия.
Полезные ссылки
Комментарии (41)
marshinov
27.08.2017 21:12Все о чем вы пишите уже описано в книгах по системному менеджменту. Почитайте: всегда проще учиться на чужом опыте. Управление в IT имеет гораздо больше общего со "всем остальным" управлением, чем айтишники привыкли считать.
vryashentsev Автор
27.08.2017 21:21Посоветуйте лучшую на ваш взгляд книгу по системному менеджменту.
marshinov
27.08.2017 21:33Начните с «Как преодолеть кризисы менеджмента» Ицхака Адизеса. Мне она открыла глаза на многие вещи. По проектной работе — PMBOK, но читать его очень муторно. Говорят, что лучше всего записаться на курсы, но я сам не был.
vryashentsev Автор
27.08.2017 21:42Да, PMBOK читал. С первого раза его полноценно понять не смог. Но вынес из прочтения необходимость перед тем как приступить к какому-либо делу понять как ты будешь его делать. Также перечень областей знаний очень полезен для разработки плана проекта.
Спасибо за совет книги, добавил в goodreads.AnneSmith
27.08.2017 22:32-8то есть у вас нет даже минимальных знаний по управлению проектами, но вы взялись за управление ими?
неудивительно, что у вас стоит вопрос доверия
roswell
27.08.2017 23:06+1«И тут ко всему добавилась ещё одна задача — найм и оценка будущего персонала.» После прочтения статьи сложилось впечатление, что вам не хватает толкового HR-менеджера (я не говорю о курах, что работают скорее по инерции), а такого, которому вы могли бы позволить повариться с пару месяцев в вашей каше.
vryashentsev Автор
27.08.2017 23:07+1Да, катастрофически не хватало. Возможно, он один смог бы решить мою проблему с перегрузкой.
cepappliance
29.08.2017 20:24Какого размера была у Вас команда, когда Вы «столкнулись со странной ситуацией»?
vryashentsev Автор
30.08.2017 05:36Это было уже довольно давно, поэтому не могу вспомнить точно. Примерно 12 человек, максимум 15.
cepappliance
31.08.2017 02:20Управлять одному такой командой можно, если больше ничего делать не нужно (например, взаимодействовать с заказчиком), но сложно, так как объём задач, выполняемых такой командой, вряд ли уместится в одной голове.
Идеальный вариант — две команды с тимлидами, чтобы обеспечить одинаковую приближенность к руководителю (себе). Опять же возможность карьерного роста в коллективе (если корп. культура позволяет).
Оценкой своих людей и подбором новых людей в свою команду должны заниматься тимлиды. Иначе вряд ли его/ее будут воспринимать, как руководителя. Про доверие уже поговорили ниже: )
vryashentsev Автор
28.08.2017 08:04+4Друг дал ссылку на тему доверия. Мне очень понравилась.
notdotteam.github.io/trust
Haborym
28.08.2017 13:34-1Ну вот, перед вами Винни-Пух. Как видите, он спускается по лестнице вслед за своим другом Кристофером Робином, головой вниз, пересчитывая ступеньки собственным затылком: бум-бум-бум. Другого способа сходить с лестницы он пока не знает. Иногда ему, правда, кажется, что можно бы найти какой-то другой способ, если бы он только мог на минутку перестать бумкать и как следует сосредоточиться. Но увы — сосредоточиться-то ему и некогда.
Rabajaba
28.08.2017 14:37+2Нормальный путь нормального человека без специализированного образования в управлении проектными командами. Отлично пишите, правильные выводы делаете. Не ведитесь на тролей и продолжайте развиваться!
Насчет PMBook: будьте предельно аккуратны с этими знаниями, т.к. они загоняют вас в рамки. В IT управлении действительно больше общего с "управлением" чем с "IT", но современные IT продукты создаются сильно по-другому. Тот же PMBook был написан для девелоперов(застройщиков) и хотя его адаптировали в IT очень грамотные люди, но построить здание и создать "современный" програмный продукт, на мой взгляд сильно разные вещи. Почему? У большинства "современного" it-бизнеса часто проблема с однозначной идентификацией бизнес цели. Каким бы вы не были богом менеджмента, с плавающей бизнес-целью предприятия вам не справится самому, темболее на уровне управления проектных команд. PMBook же довольно сильно опирается на стабильность этой самой первичной бизнес-цели. Сведеющие в этой теме, поправьте меня, пожалуйста, ибо читал его уже года 4 назад.
dark-pegas
28.08.2017 20:14+1Почитайте книгу «Чего хочет бизнес от IT», автор Терри Уайт. Не 100% по озвученной вами теме и проблеме, но очень близко. Возможно, найдете что-либо интересное для себя.
Ну и желаю Вам успехов в Вашем деле и эффективного решения всех проблем! :)vryashentsev Автор
28.08.2017 20:21Спасибо за рекомендацию. Судя по описанию книги, основная её мысль заключается в потере IT специалистами фокуса с денег. Эту мысль достойно доносит книжка impact mapping и мимоходом касается в книгах specification by example и bdd in action. В принципе тема мной усвоена.
cepappliance
29.08.2017 11:43+2Мне кажется, чем быстрее хорошие технари приходят к тому, что их тех.навыки применимы и в управлении людьми, тем быстрее они становятся хорошими руководителями.
Например, вопрос доверия… Какому ПО мы доверяем больше? Которое успешно прошло тестирование. Особенно, если сценарии написали мы сами (как самые опытные, знающие и т.п.) или кто-то, кому мы доверяем. Так и с человеком. Новичку можно дать задачу и выяснить, как он с ней справляется. Конечно, наши первоначальные ожидания о качестве работы человека, сформированные в ходе собеседования, должны подсказать насколько критична должна быть задача и какой контроль нужно обеспечить на период тестирования новичка.
Трудно сходу довериться новичку. Да и доверие ценится сотрудником выше, если оно заслужено. Поэтому начинать путь к доверию нужно с малого.vryashentsev Автор
30.08.2017 08:13чем быстрее хорошие технари приходят к тому, что их тех.навыки применимы и в управлении людьми, тем быстрее они становятся хорошими руководителями
А ведь я с вами согласен. А можете еще раскрыть ваше видение — какие именно «тех.навыки применимы и в управлении людьми»?cepappliance
31.08.2017 03:21Рассматривайте работу Вашего коллектива как совокупность юзкейсов или процессов, а людей — как объекты, которые их реализуют.
Процессы — это правила игры, а Ваш коллектив — группа людей, которая в нее играет. Все должны знать правила и следовать им. Вы создаете эти правила, как отражение накопленного Вами и командой опыта, и обеспечиваете их соблюдение, наблюдаете с судейской вышки и думаете, нужно ли что-то менять…
Разработка и внедрение процессов — вполне технические задачи. Согласны?
Например, то что я описал в предыдущем комментарии о доверии, можно рассматривать как юзкейс/процесс «Адаптация новичка» («Внедрение нового модуля/функционала в работающую систему»).
Как обеспечить соблюдение правил? Следование правилам — это в некотором смысле естественная потребность людей, потому что при наличии правил понятно, что ждут от тебя и что ты можешь ждать от других. Нужно только убедиться, что правила разумны, честны, понятны и подъемны. И не бояться их менять, если пришло время.
И где то там в облаках летают мотивация, эмоциональная зрелость, навыки Ваших людей и т.п. Без учета всего этого будет трудно поддерживать боевой дух в коллективе.vryashentsev Автор
31.08.2017 07:07Большой комментарий. Буду отвечать по частям.
Рассматривайте работу Вашего коллектива как совокупность юзкейсов или процессов, а людей — как объекты, которые их реализуют.
Данное представление как будто упрощает людей. Человеческий фактор не зря считается серьезным источником сложностей. Почему же вы так упрощаете отношения людей? Человек это объект с неизвестным иррациональным поведением. Аналогию с объектами вряд ли можно считать практичной.
Процессы — это правила игры, а Ваш коллектив — группа людей, которая в нее играет. Все должны знать правила и следовать им. Вы создаете эти правила, как отражение накопленного Вами и командой опыта, и обеспечиваете их соблюдение, наблюдаете с судейской вышки и думаете, нужно ли что-то менять…
Тут согласен.
Разработка и внедрение процессов — вполне технические задачи. Согласны?
Я не видел в работе программиста такой работы с процессами, которая помогла бы ему в дальнейшем управлять людьми. Поэтому формально с утверждением я согласен, а вот с вероятным выводом из этого утверждения — нет.
Как обеспечить соблюдение правил? Следование правилам — это в некотором смысле естественная потребность людей, потому что при наличии правил понятно, что ждут от тебя и что ты можешь ждать от других. Нужно только убедиться, что правила разумны, честны, понятны и подъемны. И не бояться их менять, если пришло время.
Соглашусь.
И где то там в облаках летают мотивация, эмоциональная зрелость, навыки Ваших людей и т.п. Без учета всего этого будет трудно поддерживать боевой дух в коллективе.
Согласен. Только тех. навыки тут совсем не помогают.
Давайте вернемся к исходному вопросу — какие именно, максимально конкретно, тех. навыки программиста, коли мы находимся в контексте разработки ПО, помогают ему руководить людьми? Я увидел много слов, но к сожалению не увидел ответа. Могу своё видение описать, но хочу все таки сначала увидеть ваше, чтобы исключить влияние.cepappliance
31.08.2017 10:08+1Почему же вы так упрощаете отношения людей? Человек это объект с неизвестным иррациональным поведением.
В общем случае — да, действительно, не так просто.
Но человек в коллективе, с которым Вы договорились играть по определенным правилам, как бы встроили в систему, подключили, не так уж и иррационален. Он знает, что от него ждут и что он может ждать от других. И он может через это сам себя оценивать (обратная связь) и корректировать свои действия. Далее все зависит от его/ее опыта, эмоциональной зрелости, воспитанности. Не нужно забывать, что не только руководитель может предъявить претензии о несоблюдении правил игры, но и члены коллектива могут предъявить их руководителю и другим членам команды (иногда такие отношения обретают даже формализованный вид, называются ретроспективами — чтобы коллектив не забывал о своих правах). Если человек идет сознательно (понять это — задача руководителя) на нарушение правил, то справедливо может ожидать, что в отношении него будут применены какие то корректирующие действия. Важно, чтобы правила были прозрачны. И одинаковы для всех. Обеспечение этого — задача руководителя.
Часто за иррациональным поведением (как нам оно видится со стороны) скрывается непонимание/незнание/неумение (тех. навыки), неудовлетворенность.
Итак, коллектив — это система. Процессы — юзкейсы. Строим организацию коллектива — проектируем систему, разбиваем ее на подсистемы (разработка, тестирование и т.п.), модули (команды) и объекты (люди). Инкапсуляция — запрет на микроменеджмент, взаимодействие через интерфейс желательно с известными пред- и постусловиями, инвариантами (контрактное программирование). Нагрузка на команду высокая — вводим балансировщик. Команда продуктовая (должна жить долго) — внедряем DR, дублирование…vryashentsev Автор
31.08.2017 10:57Спасибо за разъяснение. Но все равно, звучит как теория. То ли вы не проходили на практике, то о чем пишете, то ли наоборот этот успешный опыт у вас уже давно в бессознательном. Вы строили команды? Вот, прямо лично вы, строили? Не наблюдали, не помогали, а строили? Если так — напишите об этом статью, пожалуйста. На примере легче понять и поверить.
Но мысли, точно, годные. Еще раз спасибо.
vryashentsev Автор
31.08.2017 07:21Ладно, чего я умничаю. Вот моё видение.
Принципы SOLID.
Об ограничении рабочих функций:
- Принцип единственной ответственности
- Принцип разделения интерфейсов.
О взаимозаменяемости кадров, о важности ролей:
- Принцип инверсии зависимостей.
- Принцип подстановки Барбары Лисков.
AnneSmith
невозможно контролировать доверие до уровня стопроцентной уверенности в стопроцентном результате
в проекте работают люди, а не роботы, и всегда возможны и будут варианты, даже если вы нанимаете супер профессионалов, может даже оказаться, что уровень вашего собственного профессионализма ниже профессионализма тех, кому вы не доверяете
поэтому должен быть выстроен процесс контроля за качеством в течение цикла каждого модуля, а не только проекта в целом, а работа руководителя проекта — контроль за этим качеством на каждом этапе и оценка рисков, а не параноидальное «доверие», тем более что в 99% случаев руководитель проекта не может выбирать людей по личному вкусу и работает с тем, что есть, особенно если часть проекта отдается сторонним организациям
vryashentsev Автор
Откровенно говоря, я не вижу противоречий ваших слов моим. Да, стопроцентной уверенности быть не может и уж тем более гарантий.
Я понимаю, что уровень профессионализма сотрудника может быть выше уровня профессионализма руководителя. Хотя не понимаю как можно сравнивать профессионализм в управлении с профессионализмом в разработке. Но я соглашусь, что такое бывает и считаю такую ситуацию крайне удачной!
Как из вышеизложенного вытекает, что должен быть выстроен контроль качества я тоже не понял. Но соглашусь что да, действительно должен. Чаще всего.
Но не теряйте контекста статьи, а он такой — «как снять с себя непрофильные обязанности и заняться тем чем мне должно заниматься».
AnneSmith
ваш профессионализм в вашей сфере может быть ниже уровня профессионализма специалиста, которым вы руководите, то есть разработчик может сделать вашу работу лучше вас и скорее всего делает во многих ситуациях, а вы не сможете сделать его работу вообще, но при этом у вас хватает ума еще ему и не «доверять» :)
необходимость контроля качества вытекает не из вышеизложенного, а из системы управления проектами
снять с себя непрофильные обязанности и при этом обеспечить успешное выполнение проекта невозможно без инструмента контроля за выполнением
если вы не знаете, как выстраивать процесс контроля за качеством, то что вы делаете в руководстве проектом?
vryashentsev Автор
Вы привели очень интересный вымышленный пример с профессионализмом. Такого в моей жизни еще не было. Думаю я бы поучился у такого специалиста, который к тому же имеет существенный опыт в управлении, с большим удовольствием.
Приведу вам ваши же слова:
И далее
Вы действительно считаете, что процесс контроля за качеством должен быть выстроен именно «поэтому» или уже не считаете так? :)
Ну и опять таки постарайтесь обосновать ваши выводы о моей компетенции.
AnneSmith
на мой вопрос вы не посчитали нужным ответить, но ждете ответа на ваш? :)
плюс косвенно обвинили меня во вранье
думаю, тут все прозрачно
vryashentsev Автор
Заходите еще, возможно моя следующая статья понравится вам больше. У меня еще есть несколько тем, мыслями по которым я хочу поделиться с сообществом.
Посоветуйте лучшую, на ваш взгляд, книгу по организации контроля качества.
AnneSmith
извините, мне ваш невежливый стиль общения совсем не импонирует
да и мысли ваши тоже представляют мало интереса
BelBES
Так вроде бы общепринято считать, что начиная с сеньорных грейдов, "разработчики" становятся теми людьми, которые способны объединять в себе функции как непосредственно разработчика, так и руководителя… не?
vryashentsev Автор
Нет общепринятой классификации уровней разработчиков, Так что не знаю о каком общепринятом мнении речь. И я убеждён, что умение руководить не зависит от компетенции в разработке.
BelBES
Эмм…
1) Большинство компаний, как минимум достаточно крупных, придерживаются разделения на Junior, Middle, Senior (а где-то и больше) грейды… при этом есть некие общие черты, по уровням компетенции, использующиеся в разных компаниях… где в настоящее время не придерживаются данной "классификации" в IT компаниях?
2) Что такое в данном случае понимается под "умением руководить"? Ну и в целом Ваше утверждение весьма спорное: без достаточной компетенции в вопросе, менеджер легко может оказаться в роли самодура, не понимающего, какие у команды могут возникнуть проблемы при решении поставленых задач в установленые сроки.
vryashentsev Автор
Да, в вакансиях пишут эти названия уровней, но это очень расплывчатые понятия, которые понимаются по-разному в разных местах. В том числе поэтому я и утверждаю, что общепринятой классификации нет.
Как раз вчера общался с руководителем, учредителем двух компаний, руководитель направления в одной немецкой компании. Он в итоге пришел к выводу, что руководитель должен разбираться в людях и управлении, но ни в коем случае не должен пытаться сделать дело своими руками — это отвлекает от основной обязанности — управления. Хорошо я он вышел из разработки.
Может ли руководитель оказаться самодуром? Ещё как может! И разработческое прошлое от этого не спасает.
Руководство = управление.
vryashentsev Автор
Не уследил за автокомплитом.
«Хотя он вышел из разработки»
«руководитель направления в одной немелкой компании»
vryashentsev Автор
Чтобы наш разговор был более предметным я предлагаю вам описать ваше понимание Senior, а читатели пояснят где ваше мнение отличается от их. И т.к. стандарта нет, то вы ведь позволите им иметь собственное мнение?
BelBES
Традиционно, как в "одной немелкой компании", в которой я работаю в настоящее время, так и в достаточно большом числе других компаний, с которыми я когда-либо пересекался, вот конкретно эти 3 грейда делят примерно как:
1) Junior — спциалист, который умеет программировать, но не имеет достаточного опыта в инженерии и процессах, в связи с чем может неверно оценивать приоритеты по задачам и работать не достаточно эффективно. Для его эффективной работы требуется супервайзер, который будет учавствовать при составлении roadmap'ов, и контролировать процесс работы.
2) Middle — специалист, который умеет программировать и в целом имеет представление о процессах и углубленную экспертизу в своей области, что позволяет ему выступать в роли эксперта в области своих компетенций внутри компании. Может как самостоятельно заниматься работой над существенными частями проекта, так и выступать в роли супервайзера для джуниоров. При составлении roadmap'ов ему так-же требуется супервайзер, который поможет при расстановке приоритетов.
3) Senior — специалист, который имеет обширную экспертизу, понимает процесса внутри компании. Персонаж довольно автономный, которому достаточно указывать "великие цели" и сроки, после чего он может самостоятельно организоваться сам и организовать коллег, может заниматься непосредственным составлением roadmap'ов, выступать в роли овнера проектов и тд и тп. Может активно учавствовать в митингах с заказчиками и учавствовать в том числе и в составлении глобальных roadmap'ов.
Вот примерно как-то так…
И в компании на ~100 человек у нас это работало, и в компании на ~100K человек все ± то же самое.
APAKS
Не понимаю, чему вы удивляетесь (уже несколько раз в комментариях) в вопросе "что вы делаете в управлении проектами, если не умеете управлять". В идеальном мире и в большой организации пожалуй да, этим занимается опытный человек. Но в реальном мире очень много небольших команд, в которых отдельный управленец — непозволительная роскошь. Да и работы ему на фуллтайм не найдется. Поэтому, управлением занимается наиболее опытный член команды, который на первых порах как раз и не имеет никаких навыков в этой сфере, учится на ошибках и читает книжки. И "зашивается" так же, как и автор статьи.
AnneSmith
тогда может быть имеет смысл поручить эту нелегкую миссию тем, кто умеет организовывать хотя бы свою работу без зашиваний?
ах да, им же не доверяют :)