Пригласили на работу на замену руководителю IT-отдела

2009-12-02 02:40:19

V.N. [nnseva@gmail.com] » Всем

Здравствуйте. Ситуация следующая.

Меня пригласили на работу руководителем отдела разработки программного обеспечения перспективного ИТ проекта.

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

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

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

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

Прав ли мой наниматель? Какие еще варианты более мягких решений существуют? Что бы Вы посоветовали в данной ситуации?

(PS: прошу прощения за временно сокращенное до инициалов имя)

Ответить Сообщение для всех [Показать все ответы на это сообщение]

2009-12-03 07:23:49

Сергей В. Сычев [sch@triz-ri.ru] » V.N.

Уважаемый Коллега!

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

----

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

Спасибо,

Ответить Сообщение для всех [Показать все ответы на это сообщение]

2009-12-03 14:46:48

V.N. [nnseva@gmail.com] » Сергей В. Сычев

Прошу прощения, но сравнение не совсем корректно.

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

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

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

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

Речь идет о:

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

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

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

Ответить Сообщение для всех [Показать все ответы на это сообщение]

2009-12-03 15:54:32

Сергей В. Сычев [sch@triz-ri.ru] » V.N.

Уважаемый Коллега!

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

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

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

Это очень плохо. Вам надо это изменить.

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

Вероятно, как специалист, Вы можете предложить решения. Предложите их.

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

Например, можно подумать над задачей сбора информации. Можете привести 6-7 характерных примеров таких "мелких, но сущственных деталей процесса".

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

Этот риск Вы никак не устраните. Даже, если квалифицированно перехватите разработку, файлы там останутся. Но будут ли они обладать рыночной ценностью вне компании, которая будет продвигать продукт на рынок (если я верно понял)? Тем более, если там много чего состоит из деталей, которые не зафиксированы ни в каком виде, кроме нейронных связей в голове... Сосредоточьтесь на приведении процесса разработки в порядок, на документировании и т.д.

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

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

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

Да. "Личные качества" лучше вынести за скобки. Лучше сосредоточиться на самом проекте.

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

Здесь ложное противопоставление (между первым и вторым предложением). И почему же Вам наплевать на то, чего от Вас ждут?

Спасибо,

Ответить Сообщение для всех [Показать все ответы на это сообщение]

2009-12-03 18:20:48

V.N. [nnseva@gmail.com] » Сергей В. Сычев

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

Как руководитель и как специалист, я обязан предоставить максимум информации для принятия решения директору, в том числе - варианты такого решения, о чем в частности был первоначальный вопрос. И кстати, еще не руководитель, пока только в процессе ...

Это очень плохо. Вам надо это изменить.

Разумеется, хотя до конца от этого фактора невозможно избавиться никогда.

Вероятно, как специалист, Вы можете предложить решения. Предложите их.

Уже, уже. Список рисков с качественной оценкой вероятности и ущерба от каждого, мероприятия по минимизации, все описано и находится у директора. Хоть я и не безопасник.

Можете привести 6-7 характерных примеров таких "мелких, но сущственных деталей процесса".

Легко. Параметры командной строки, или переменных окружения при сборке программы. Например в каком-то конкретном случае нужно, чтобы PYTHON_PATH содержал дополнительный каталог. Глюки инструмента разработки и способы их обхода. Например при использовании PowerBuilder не стоит использовать частичную сборку для получения продукта, а всегда надо пересобирать программу целиком. Visual Studio нужно периодически выгружать и снова запускать. Такие детали - как грабли в темной комнате. Есть те, кто прошел по этим граблям и получил от каждых по лбу. Конечно, можно еще разок походить, получить и запротоколировать, можно и нужно воспользоваться собственным опытом в других проектах, но человек, который уже имеет шишки набитые именно в данном месте, имеет вполне конкретную ценность, зная где именно разложены грабли. Да и не каждые грабли срабатывают сразу и явным образом. Та же программа, неправильно собранная PowerBuilder, может начать работать, но неожиданно начать глючить в самых замысловатых местах.

Этот риск Вы никак не устраните. Даже, если ...

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

будут ли они обладать рыночной ценностью вне компании

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

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

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

Здесь ложное противопоставление (между первым и вторым предложением). И почему же Вам наплевать на то, чего от Вас ждут?

"Ждут" люди, у которых есть собственное представление о том, что надо, а что не надо, и для чего именно. А людям свойственно ошибаться. Я не могу полагаться на чужие ожидания при выборе своего пути. Отсюда и противопоставление. К тому же, есть еще разные интересы - владельца, руководителей - каждого по отдельности и всех в целом, - самого проекта как отдельной сущности ... Мой интерес - в развитии проекта, интерес не совсем материальный, мне просто интересно, что из всего этого получится - с этого я начал свой первый пост.

Да, пожалуй об интересах стОит подумать дополнительно. Я сделаю это, спасибо за подсказку.

Ответить Сообщение для всех [Показать все ответы на это сообщение]

2009-12-03 18:56:44

Сергей В. Сычев [sch@triz-ri.ru] » V.N.

Уважаемый Коллега!

Есть те, кто прошел по этим граблям и получил от каждых по лбу.

А кто их раскладывал? Наверное тот, кто надеялся только на свои нейронные связи.

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

Конечно.

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

Обычно те, кто "раскладывает грабли" плохо помнит обо всех из них.

Теперь займемся детализацией.

1. Параметры командной строки, или переменных окружения при сборке программы.

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

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

1.1. ......................
1.2. ......................
1.3. ......................
1...........................
1.N. ......................

2. Глюки инструмента разработки и способы их обхода.

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

Завершите предложение: "И поэтому в проекте, которым я руковожу ............................."

2.2. Visual Studio нужно периодически выгружать и снова запускать.

Завершите предложение: "И поэтому в проекте, которым я руковожу ............................."

2.3. Программа, неправильно собранная PowerBuilder, может начать работать, но неожиданно начать глючить в самых замысловатых местах.

Завершите предложение: "И поэтому в проекте, которым я руковожу ............................."

3. Есть ли п.3., имеющий отношение к проекту?

==================================================================================

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

Это не дух, а душок.

Человек в Компании работает ЗА ДЕНЬГИ. Имущественные права на произведения созданные в рабочее время за деньги Заказчика принадлежат Компании. Так и по Закону, и по Совести. Когда есть (например) непонимание модели зарплаты и/или непонимание своих функций - это следует обсуждать и договариваться - на то и бизнес. Прочее - от лукавого.

Да, пожалуй, об интересах стОит подумать дополнительно. Я сделаю это, спасибо за подсказку.

Пожалуйста. Речь идет не о чьих-то интересах, а о заданиях, которые Вы получили. И о тех функциях, которые Вам поручено выполнять.

Разумеется, хотя до конца от этого фактора невозможно избавиться никогда.

Избавьтесь на 80%. Cм. также здесь.

Спасибо,

Ответить Сообщение для всех [Показать все ответы на это сообщение]

2009-12-03 20:53:51

V.N. [nnseva@gmail.com] » Сергей В. Сычев

Завершите предложение: "И поэтому в проекте, которым я руковожу ............................."

Я прекрасно понимаю, что именно надо делать в каждой конкретной ситуации. Этому я учился на собственных синяках и шишках. Набитых граблями, которые никто специально не раскладывает. Которые даны нам в ощущениях - и очень иногда болезненных. <флейм>Одно из таких ощущений - после 3-х часовой процедуры тщательно описанной в специальном руководстве установки и настройки сложного и дорогого программного пакета он, что характерно, отказывается работать! И отказывается до тех пор, пока при установке (!) ОС (Windows тогда еще 95), на которую устанавливается сам пакет, указывается русскоязычное наименование компании-владельца лицензии Windows. Да, приблизительно за 3 дня проблема была локализована и устранена. Да, компания-разработчик никаких внятных рекомендаций не дала. Нет, мы не могли отказаться от покупки, пакет выполнял уникальные, необходимые нам для работы, функции. Нет, это не особый случай, это рядовое происшествие из разряда как раз тех самых граблей, такое происходит повсеместно, можете поинтересоваться у разработчиков движка Вашего форума.</флейм> Одно из базовых эмпирических правил программирования - "любая непустая программа содержит ошибки. Если вы не обнаружили ошибок - значит, их количество четно".

Человек в Компании работает ЗА ДЕНЬГИ.

Продолжая Ваш шаблон - "в проекте, которым я руковожу, " человек, работающий в Кампании только ЗА ДЕНЬГИ, просто не приживется. Не потому, что кто-то специально будет его выживать, нет, ему просто будет неинтересно (деньги не те), а другим - неинтересно с ним (а чо он техзадания ждет?). Да, такой подход грозит проблемами при смене состава - но это тот подход, который единственный приводит к появлению чего-то нового - а это одна из основных моих задач.

Имущественные права на произведения созданные в рабочее время за деньги Заказчика принадлежат Компании.

Так заказчику или компании? Впрочем, не важно. Вот я будучи еще простым программером, задавал вопрос своему нанимателю - а как считать решения, пришедшие между третьим и четвертым часом ночи? Или их следует забывать по прибытию на рабочее место? Мозг не включается и не выключается по звонку. Можно отсчитывать по техзаданию - но куда девать то полезное, что сделано за его рамками? Отрезать нафиг "лишнюю функциональность", как делают в HP, судя по приведенной вами ссылке? Да, так можно сделать 25-ю версию драйвера, и если я буду заниматься производством драйверов, я так и буду поступать. Но кто-то когда-то разработал PCL (язык управления заданиями на печать), применяемый в принтерах этой уважаемой фирмы практически без изменений лет уже как 15. Я не думаю, что тот парень работал с 8 до 5 и уходил обедать с 13 до 14 часов. Если бы ваши менеджеры чуть раньше появились в HP, тому парню отрезали бы функциональность по самое немогу, а мир остался бы без PCL. Не знаю, как они там решили насчет собственности, надеюсь, парня не обидели, и все остались довольны.

Ответить Сообщение для всех [Показать все ответы на это сообщение]

2009-12-04 12:33:12

Сергей В. Сычев [sch@triz-ri.ru] » V.N.

Добрый день!

Я прекрасно понимаю, что именно надо делать в каждой конкретной ситуации...

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

1. Параметры командной строки, или переменных окружения при сборке программы.

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

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

1.1. ......................
1.2. ......................
1.3. ......................
1...........................
1.N. ......................

2. Завершите предложения:

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

2.2. "Поскольку Visual Studio нужно периодически выгружать и снова запускать, в проекте которым я руковожу .................................... "

3. "Программа, неправильно собранная PowerBuilder, может начать работать, но неожиданно начать глючить в самых замысловатых местах".

3.1. Перечислите на примерах, что означает для Вашего проекта (а не вообще) фраза "неправильно собранная":

Пример 1 (неправильной сборки). ....................................................

Пример 2 (неправильной сборки). ....................................................

Пример 3 (неправильной сборки). ....................................................

.............................. и т.д. ....................................................................

Пример N (неправильной сборки). ....................................................

3.2. Приведите 2-3 конкретных примера "замысловатых мест", но не вообще, а имеющих отношения к Вашему проекту.

после 3-х часовой процедуры тщательно описанной в специальном руководстве установки и настройки сложного и дорогого программного пакета он, что характерно, отказывается работать! И отказывается до тех пор, пока при установке (!) ОС (Windows тогда еще 95) (...) и т.д.

Эта история имеет отношение к проекту, которым Вы руководите сейчас? Если имеет, я попрошу детализировать задачу.

...такое происходит повсеместно,..

Нет.

...можете поинтересоваться у разработчиков движка Вашего форума...

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

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

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

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

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

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

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

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

...Продолжая Ваш шаблон - "в проекте, которым я руковожу, " человек, работающий в Кампании только ЗА ДЕНЬГИ, просто не приживется. Не потому, что кто-то специально будет его выживать, нет, ему просто будет неинтересно (деньги не те)...

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

Иными словами: согласились работать на таких условиях = надо работать ОК и не пенять.

а другим - неинтересно с ним (а чо он техзадания ждет?).

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

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

Ни к чему новому это не приводит. Это приводит только к тому бардаку, перед которым Вы стоите.

Так заказчику или компании?

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

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

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

Если Ваш работодатель обратится, можем прислать модель.

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

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

Легко быть философом за чужой счет. Вы сначала сами

Отрезать нафиг "лишнюю функциональность", как делают в HP, судя по приведенной вами ссылке? Да, так можно сделать 25-ю версию драйвера, и если я буду заниматься производством драйверов, я так и буду поступать.

Когда Вы достигнете уровня НР, мы с Вами обсудим и этот вопрос.

Всего хорошего,

Ответить Сообщение для всех [Показать все ответы на это сообщение]

2009-12-04 17:18:36

V.N. [nnseva@gmail.com] » Сергей В. Сычев

Уважаемый Сергей,

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

Также уточнение в посте от 03.12.2009 18:20:48
И кстати, еще не руководитель, пока только в процессе ...

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

Поэтому, когда мне станут известны все детали, которые имеют отношение к данному проекту, а станут они мне известны не ранее, чем я действительно приступлю к работе, я обязательно постараюсь детализировать все подробности, которые могли остаться неизвестными в результате перехода, и мне не надо объяснять необходимость данного шага, он для меня очевиден. Также для меня очевидна необходимость планирования разработки, ведения дневника проекта, разработка таких документов как списки требований, архитектура системы, техническое задание как для проекта в целом, так и для отдельных элементов проекта, и так далее. Этим я занимался и раньше, этим буду заниматься и сейчас. И в любом проекте, которым я руковожу, эти процессы происходили и будут происходить, а соответствующие инструменты - применяться. Я хорошо знаком с Rational Unified Process, и применяю его элементы в своей работе. Недавно мне случилось ознакомиться со SCRUM, оказалось, что его элементы я тоже применяю. Так же я использую кое-какие приемы из eXtremal Programming.

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

Я благодарен Вам за Ваши советы и рекомендации, но они касаются того момента, когда моя работа уже началась. А она еще не начиналась.

Еще один момент касается особого статуса данного проекта. Это - стартап. Поясняю. Когда Стив Джобс сделал в своем гараже свой первый персональный комп, это был стартап. Когда он пришел в хорошо структурированную IBM и предложил выпускать его детище, они отказались - и прежде всего, как мне кажется, отказались по причине своей структурированности. Не думаю, что Стив начинал с технического описания своего творения, или писал к нему техзадание. Когда Линус Торвальд написал новое ядро для своей системы, гордо назвав ее Линуксом, это тоже был стартап. Ядро Линукса до сих пор не документировано должным, с точки зрения структурированной разработки, образом, но пока народу хватает заголовочных файлов и манов по ядерным функциям.

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

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

Пока!

Ответить Сообщение для всех [Показать все ответы на это сообщение]

2009-12-04 18:50:53

Сергей В. Сычев [sch@triz-ri.ru] » V.N.

Добрый день!

Относительно того прав или нет руководитель.

1. Он прав в том, что хочет "перехватить" проект, минимизируя риски.

2. Возможно он неправ в том способе, который намерен применить. Но его проблема рациональная и понятная.

3. Для того, чтобы ему помочь (а я полагаю, что он рассчитывал на Вашу помощь), надо диагностировать настоящую проблему. И, в этой связи, важно понять, что ситуация, с которой столкнулся руководитель фирмы, произошла, в немалой степени, из-за неорганизованности/запущенности работы IT-отдела.

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

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

Кроме того, во времена, о которых Вы пишете, фирма "Apple" была в полном ауте, а весь мир заполоняли, как раз, "IBM-совместимые" компьютеры.

Ядро Линукса до сих пор не документировано должным, с точки зрения структурированной разработки, образом, но пока народу хватает заголовочных файлов и манов по ядерным функциям.

Какому народу? Узкому кругу фанатов. Кроме того, проект о которым Вы пишете здесь (а не Linux), очевидно, находится в таком состоянии, что даже не узкому круг фанатов, а небольшому отделу явно не хватает заголовочных файлов и манов. Иначе описываемая ситуация не возникла бы. И в этом сердцевина задачи.

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

Я Вам рекомендую не занимать эту должность. Подход, который Вы исповедуете, уже довел фирму, в которую Вас пригласили, до "партизанских методов". Не надо ее мучать второй раз.

С Уважением,

Ответить Сообщение для всех [Нет ответов на это сообщение]

TRIZ-RI Group

Как выявить критерии результативности таксиста?

Обсуждения-аналоги

Авторы

На ту же тему

TRIZ-RI Group

Что делать с персоналом, который не хочет работать?