精华内容
下载资源
问答
  • 为什么家里pm25比外面高
    千次阅读
    2020-12-10 22:56:39

    上一节我讲了 CPU 使用率是什么,并通过一个案例教你使用 top、vmstat、pidstat 等工具,排查高 CPU 使用率的进程,然后再使用 perf top 工具,定位应用内部函数的问题。不过就有人留言了,说似乎感觉高 CPU 使用率的问题,还是挺容易排查的。

    那是不是所有 CPU 使用率高的问题,都可以这么分析呢?我想,你的答案应该是否定的。

    回顾前面的内容,我们知道,系统的 CPU 使用率,不仅包括进程用户态和内核态的运行,还包括中断处理、等待 I/O 以及内核线程等。所以,当你发现系统的 CPU 使用率很高的时候,不一定能找到相对应的高 CPU 使用率的进程。

    今天,我就用一个 Nginx + PHP 的 Web 服务的案例,带你来分析这种情况。

     

    操作和分析


     首先,我们在第一个终端,执行下面的命令运行 Nginx 和 PHP 应用:

    [root@localhost ~]# docker run --name nginx -p 10000:80 -itd feisky/nginx:sp
    724f49267a44fe533de12be885940bb84ff109ccc4eef00d08a705d72e573bd8
    [root@localhost ~]# docker run --name phpfpm -itd --network container:nginx feisky/php-fpm:sp
    cc4ff1700f3e17da7757e2565542325b34853bba5c17f7d53626558699b66f71

    然后,在第二个终端,使用 curl 访问 http://[VM1 的 IP]:10000,确认 Nginx 已正常启动。你应该可以看到 It works! 的响应。

    # 192.168.179.99是第一台虚拟机的IP地址
    [root@localhost ~]# curl 192.168.179.99:10000
    It works!

    接着,我们来测试一下这个 Nginx 服务的性能。在第二个终端运行下面的 ab 命令。要注意,与上次操作不同的是,这次我们需要并发 100 个请求测试 Nginx 性能,总共测试 1000 个请求。

    # 并发100个请求测试Nginx性能,总共测试1000个请求
    [root@localhost ~]# ab -c 100 -n 1000 http://192.168.179.99:10000/
    This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
    ...
    Requests per second:    87.86 [#/sec] (mean)
    Time per request:       1138.229 [ms] (mean)
    ...

    从 ab 的输出结果我们可以看到,Nginx 能承受的每秒平均请求数,只有 87 多一点,是不是感觉它的性能有点差呀。那么,到底是哪里出了问题呢?我们再用 top 和 pidstat 来观察一下。

    这次,我们在第二个终端,将测试的并发请求数改成 5,同时把请求时长设置为 10 分钟(-t 600)。这样,当你在第一个终端使用性能分析工具时, Nginx 的压力还是继续的。

    继续在第二个终端运行 ab 命令:

    [root@localhost ~]# ab -c 5 -t 600 http://192.168.179.99:10000/
    This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
    Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
    Licensed to The Apache Software Foundation, http://www.apache.org/
    
    Benchmarking 192.168.179.99 (be patient)

    然后,我们在第一个终端运行 top 命令,观察系统的 CPU 使用情况:

    [root@localhost ~]# top
    top - 17:22:58 up 1 day, 17:43,  5 users,  load average: 2.82, 1.98, 1.22
    Tasks: 131 total,   6 running, 125 sleeping,   0 stopped,   0 zombie
    %Cpu(s): 84.1 us, 13.3 sy,  0.0 ni,  1.4 id,  0.0 wa,  0.0 hi,  1.2 si,  0.0 st
    KiB Mem :  1765672 total,   143216 free,   186828 used,  1435628 buff/cache
    KiB Swap:   524284 total,   478172 free,    46112 used.  1267828 avail Mem 
    
       PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                          
     76584 101       20   0   33092   2200    776 S   2.7  0.1   0:01.41 nginx                                            
     79643 bin       20   0  336684   7696   1912 S   1.7  0.4   0:00.68 php-fpm                                          
     79648 bin       20   0  336684   7684   1900 S   1.7  0.4   0:00.70 php-fpm                                          
     79657 bin       20   0  336684   7696   1912 S   1.7  0.4   0:00.65 php-fpm                                          
     79664 bin       20   0  336684   7684   1900 S   1.7  0.4   0:00.69 php-fpm                                          
     79642 root      20   0   60024   3000   2240 S   1.3  0.2   0:00.58 ab                                               
     79667 bin       20   0  336684   7688   1904 R   1.3  0.4   0:00.65 php-fpm                                          
     17478 root      20   0  627164  71076  27432 S   1.0  4.0   3:18.93 dockerd                                          
     76541 root      20   0  109096   3736   2700 S   1.0  0.2   0:00.50 containerd-shim                                  
     76611 root      20   0  336300  33092  27696 S   0.3  1.9   0:00.21 php-fpm                                          
     89786 bin       20   0    8176    600    104 R   0.3  0.0   0:00.01 stress                                           
     89788 bin       20   0    8176    604    104 R   0.3  0.0   0:00.01 stress                                           
         1 root      20   0  125600   2712   1564 S   0.0  0.2   0:18.39 systemd          

    观察 top 输出的进程列表可以发现,CPU 使用率最高的进程也只不过才 2.7%,看起来并不高。

    然而,再看系统 CPU 使用率( %Cpu )这一行,你会发现,系统的整体 CPU 使用率是比较高的:用户 CPU 使用率(us)已经到了 84.1%,系统 CPU 为 13.3%,而空闲 CPU (id)则只有 1.4%。

    为什么用户 CPU 使用率这么高呢?我们再重新分析一下进程列表,看看有没有可疑进程:

    1. Nginx 和 php-fpm 是运行 Web 服务的,它们会占用一些 CPU 也不意外,并且 1% 的 CPU 使用率也不算高
    2. 再往下看,后面的进程呢,只有 0.3% 的 CPU 使用率,看起来不太像会导致用户 CPU 使用率达到 80%

    那就奇怪了,明明用户 CPU 使用率都 80% 了,可我们挨个分析了一遍进程列表,还是找不到高 CPU 使用率的进程。看来 top 是不管用了,那还有其他工具可以查看进程 CPU 使用情况吗?不知道你记不记得我们的老朋友 pidstat,它可以用来分析进程的 CPU 使用情况。 

    接下来,我们还是在第一个终端,运行 pidstat 命令:

    # 间隔1秒输出一组数据(按Ctrl+C结束)
    [root@localhost ~]# pidstat 1
    ...
    05:26:08 PM   UID       PID    %usr %system  %guest    %CPU   CPU  Command
    05:26:09 PM     0      3026    0.00    1.00    0.00    1.00     1  pidstat
    05:26:09 PM     0     29992    0.00    1.00    0.00    1.00     1  kworker/1:0
    05:26:09 PM     0     76541    0.00    1.00    0.00    1.00     0  containerd-shim
    05:26:09 PM   101     76584    0.00    3.00    0.00    3.00     0  nginx
    05:26:09 PM     0     79642    0.00    1.00    0.00    1.00     1  ab
    05:26:09 PM     1     79643    0.00    2.00    0.00    2.00     1  php-fpm
    05:26:09 PM     1     79648    0.00    1.00    0.00    1.00     0  php-fpm
    05:26:09 PM     1     79657    0.00    1.00    0.00    1.00     0  php-fpm
    05:26:09 PM     1     79664    0.00    2.00    0.00    2.00     0  php-fpm
    05:26:09 PM     1     79667    0.00    1.00    0.00    1.00     1  php-fpm
    ...

    观察一会儿,你是不是发现,所有进程的 CPU 使用率也都不高啊,最高的 pidstat 和  kworker/1:0 也只有 1% 和 1%,即使所有进程的 CPU 使用率都加起来,也不过是 21%,离 80% 还差得远呢!

    最早的时候,我碰到这种问题就完全懵了:明明用户 CPU 使用率已经高达 80%,但我却怎么都找不到是哪个进程的问题。到这里,你也可以想想,你是不是也遇到过这种情况?还能不能再做进一步的分析呢?

    后来我发现,会出现这种情况,很可能是因为前面的分析漏了一些关键信息。你可以先暂停一下,自己往上翻,重新操作检查一遍。或者,我们一起返回去分析 top 的输出,看看能不能有新发现。

    现在,我们回到第一个终端,重新运行 top 命令,并观察一会儿:

    [root@localhost ~]# top
    top - 17:31:22 up 1 day, 17:51,  6 users,  load average: 6.39, 5.64, 3.42
    Tasks: 131 total,   6 running, 124 sleeping,   0 stopped,   0 zombie
    %Cpu(s): 80.4 us, 11.7 sy,  0.0 ni,  7.3 id,  0.0 wa,  0.0 hi,  0.7 si,  0.0 st
    KiB Mem :  1765672 total,   103596 free,   187828 used,  1474248 buff/cache
    KiB Swap:   524284 total,   478192 free,    46092 used.  1256084 avail Mem 
    
       PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                          
     76584 101       20   0   33092   2200    776 S   2.7  0.1   0:15.00 nginx                                            
     79643 bin       20   0  336684   7708   1924 S   1.7  0.4   0:08.76 php-fpm                                          
     79657 bin       20   0  336684   7704   1920 S   1.7  0.4   0:08.56 php-fpm                                          
     79642 root      20   0   60024   4312   2320 S   1.3  0.2   0:07.06 ab                                               
     79648 bin       20   0  336684   7692   1908 S   1.3  0.4   0:08.79 php-fpm                                          
     79664 bin       20   0  336684   7696   1912 S   1.3  0.4   0:08.64 php-fpm                                          
     79667 bin       20   0  336684   7700   1916 S   1.3  0.4   0:08.48 php-fpm                                          
     76541 root      20   0  109096   3696   2708 S   1.0  0.2   0:05.49 containerd-shim                                  
     17478 root      20   0  627164  71076  27432 S   0.7  4.0   3:22.84 dockerd                                          
       962 root      20   0  562408    812    480 S   0.3  0.0   0:42.79 tuned                                            
     76652 bin       20   0    8176    600    104 R   0.3  0.0   0:00.01 stress                                           
     76653 bin       20   0    8172    596    104 R   0.3  0.0   0:00.01 stress                                           
     76660 bin       20   0    8172    600    104 R   0.3  0.0   0:00.01 stress                                           
         1 root      20   0  125600   2712   1564 S   0.0  0.2   0:18.41 systemd                                          
         2 root      20   0       0      0      0 S   0.0  0.0   0:00.70 kthreadd                                         
         3 root      20   0       0      0      0 S   0.0  0.0   0:20.88 ksoftirqd/0                                      
         5 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H  

    这次从头开始看 top 的每行输出,咦?Tasks 这一行看起来有点奇怪,就绪队列中居然有 6 个 Running 状态的进程(6 running),是不是有点多呢?

    回想一下 ab 测试的参数,并发请求数是 5。再看进程列表里, php-fpm 的数量也是 5,再加上 Nginx,好像同时有 6 个进程也并不奇怪。但真的是这样吗?

    再仔细看进程列表,这次主要看 Running(R) 状态的进程。你有没有发现, Nginx 和所有的 php-fpm 都处于 Sleep(S)状态,而真正处于 Running(R)状态的,却是几个 stress 进程。这几个 stress 进程就比较奇怪了,需要我们做进一步的分析。

    我们还是使用 pidstat 来分析这几个进程,并且使用 -p 选项指定进程的 PID。首先,从上面 top 的结果中,找到这几个进程的 PID。比如,先随便找一个 24344,然后用 pidstat 命令看一下它的 CPU 使用情况:

    [root@localhost ~]# pidstat -p  76652
    Linux 3.10.0-693.el7.x86_64 (localhost.localdomain) 	11/11/2020 	_x86_64_	(2 CPU)
    
    05:32:55 PM   UID       PID    %usr %system  %guest    %CPU   CPU  Command

    奇怪,居然没有任何输出。难道是 pidstat 命令出问题了吗?之前我说过,在怀疑性能工具出问题前,最好还是先用其他工具交叉确认一下。那用什么工具呢? ps 应该是最简单易用的。我们在终端里运行下面的命令,看看 24344 进程的状态:

    # 从所有进程中查找PID是76652的进程
    [root@localhost ~]# ps -aux | grep 76652
    root      89099  0.0  0.0 112660   968 pts/1    S+   17:33   0:00 grep --color=auto 76652

    还是没有输出。现在终于发现问题,原来这个进程已经不存在了,所以 pidstat 就没有任何输出。既然进程都没了,那性能问题应该也跟着没了吧。我们再用 top 命令确认一下:

    [root@localhost ~]# top
    top - 17:34:34 up 1 day, 17:55,  4 users,  load average: 1.40, 3.79, 3.14
    Tasks: 126 total,   6 running, 120 sleeping,   0 stopped,   0 zombie
    %Cpu(s): 78.4 us, 13.2 sy,  0.0 ni,  7.5 id,  0.0 wa,  0.0 hi,  0.8 si,  0.0 st
    KiB Mem :  1765672 total,   117032 free,   182640 used,  1466000 buff/cache
    KiB Swap:   524284 total,   478196 free,    46088 used.  1273212 avail Mem 
    
       PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                          
     76584 101       20   0   33092   2200    776 S   2.7  0.1   0:16.71 nginx                                            
     89102 bin       20   0  336684   7708   1924 S   2.0  0.4   0:00.17 php-fpm                                          
     89114 bin       20   0  336684   7684   1900 S   1.7  0.4   0:00.16 php-fpm                                          
     89123 bin       20   0  336684   7684   1900 S   1.7  0.4   0:00.16 php-fpm                                          
     89128 bin       20   0  336684   7684   1900 S   1.7  0.4   0:00.15 php-fpm                                          
     89106 bin       20   0  336684   7688   1904 S   1.3  0.4   0:00.16 php-fpm                                          
     89101 root      20   0   60024   3000   2240 S   1.0  0.2   0:00.13 ab                                               
     17478 root      20   0  627164  71076  27432 S   0.7  4.0   3:23.38 dockerd                                          
     76541 root      20   0  109096   3712   2708 S   0.7  0.2   0:06.13 containerd-shim                                  
       361 root      20   0   36968   5768   5544 S   0.3  0.3   0:13.45 systemd-journal                                  
     91779 bin       20   0    8172   1120    104 R   0.3  0.1   0:00.01 stress                                           
     91781 bin       20   0    8172    600    104 R   0.3  0.0   0:00.01 stress                                           
     91787 bin       20   0    8172    856    104 R   0.3  0.0   0:00.01 stress                                           
         1 root      20   0  125600   2712   1564 S   0.0  0.2   0:18.41 systemd                                          
         2 root      20   0       0      0      0 S   0.0  0.0   0:00.70 kthreadd                                         
         3 root      20   0       0      0      0 S   0.0  0.0   0:20.91 ksoftirqd/0                                      
         5 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H  

    好像又错了。结果还跟原来一样,用户 CPU 使用率还是高达 80.9%,系统 CPU 接近 15%,而空闲 CPU 只有 2.8%,Running 状态的进程有 Nginx、stress 等。

    可是,刚刚我们看到 stress 进程不存在了,怎么现在还在运行呢?再细看一下 top 的输出,原来,这次 stress 进程的 PID 跟前面不一样了,原来的 PID  76652 不见了,现在的是 91779。

    进程的 PID 在变,这说明什么呢?在我看来,要么是这些进程在不停地重启,要么就是全新的进程,这无非也就两个原因:

    • 第一个原因,进程在不停地崩溃重启,比如因为段错误、配置错误等等,这时,进程在退出后可能又被监控系统自动重启了。
    • 第二个原因,这些进程都是短时进程,也就是在其他应用内部通过 exec 调用的外面命令。这些命令一般都只运行很短的时间就会结束,你很难用 top 这种间隔时间比较长的工具发现(上面的案例,我们碰巧发现了)。

     至于 stress,我们前面提到过,它是一个常用的压力测试工具。它的 PID 在不断变化中,看起来像是被其他进程调用的短时进程。要想继续分析下去,还得找到它们的父进程。

    要怎么查找一个进程的父进程呢?没错,用 pstree  就可以用树状形式显示所有进程之间的关系:

    [root@localhost ~]# pstree | grep stress
            |            |-containerd-shim-+-php-fpm-+-4*[php-fpm---sh---stress---stress]

    从这里可以看到,stress 是被 php-fpm 调用的子进程,并且进程数量不止一个(这里是 4个)。找到父进程后,我们能进入 app 的内部分析了。

    首先,当然应该去看看它的源码。运行下面的命令,把案例应用的源码拷贝到 app 目录,然后再执行 grep 查找是不是有代码再调用 stress 命令:

    # 拷贝源码到本地
    [root@localhost ~]# docker exec -it phpfpm /bin/bash
    root@724f49267a44:/app# pwd
    /app
    root@724f49267a44:/app# ls
    404.html  index.php  ok.php  phpinfo.php
    root@724f49267a44:/app# exit
    exit
    [root@localhost ~]# docker cp phpfpm:/app .
    [root@localhost ~]# ls
    anaconda-ks.cfg  app
    
    # grep 查找看看是不是有代码在调用stress命令
    [root@localhost ~]# grep "stress" -r app/
    app/index.php:// fake I/O with stress (via write()/unlink()).
    app/index.php:$result = exec("/usr/local/bin/stress -t 1 -d 1 2>&1", $output, $status);

    找到了,果然是 app/index.php 文件中直接调用了 stress 命令。

    再来看看 app/index.php 的源代码:

    [root@localhost ~]# cat app/index.php 
    <?php
    // fake I/O with stress (via write()/unlink()).
    $result = exec("/usr/local/bin/stress -t 1 -d 1 2>&1", $output, $status);
    if (isset($_GET["verbose"]) && $_GET["verbose"]==1 && $status != 0) {
      echo "Server internal error: ";
      print_r($output);
    } else {
      echo "It works!";
    }

    可以看到,源码里对每个请求都会调用一个 stress 命令,模拟 I/O 压力。从注释上看,stress 会通过 write() 和 unlink() 对 I/O 进程进行压测,看来,这应该就是系统 CPU 使用率升高的根源了。

    不过,stress 模拟的是 I/O 压力,而之前在 top 的输出中看到的,却一直是用户 CPU 和系统 CPU 升高,并没见到 iowait 升高。这又是怎么回事呢?stress 到底是不是 CPU 使用率升高的原因呢?

    我们还得继续往下走。从代码中可以看到,给请求加入 verbose=1 参数后,就可以查看 stress 的输出。你先试试看,在第二个终端运行:

    [root@localhost ~]# curl http://192.168.179.99:10000?verbose=1
    Server internal error: Array
    (
        [0] => stress: info: [31514] dispatching hogs: 0 cpu, 0 io, 0 vm, 1 hdd
        [1] => stress: FAIL: [31515] (563) mkstemp failed: Permission denied
        [2] => stress: FAIL: [31514] (394) <-- worker 31515 returned error 1
        [3] => stress: WARN: [31514] (396) now reaping child worker processes
        [4] => stress: FAIL: [31514] (400) kill error: No such process
        [5] => stress: FAIL: [31514] (451) failed run completed in 0s
    )

    看错误消息 mkstemp failed: Permission denied ,以及 failed run completed in 0s。原来 stress 命令并没有成功,它因为权限问题失败退出了。看来,我们发现了一个 PHP 调用外部 stress 命令的 bug:没有权限创建临时文件。

    从这里我们可以猜测,正是由于权限错误,大量的 stress 进程在启动时初始化失败,进而导致用户 CPU 使用率的升高。

    分析出问题来源,下一步是不是就要开始优化了呢?当然不是!既然只是猜测,那就需要再确认一下,这个猜测到底对不对,是不是真的有大量的 stress 进程。该用什么工具或指标呢?

    我们前面已经用了 top、pidstat、pstree 等工具,没有发现大量的 stress 进程。那么,还有什么其他的工具可以用吗?

    # 记录性能事件,等待大约15秒后按 Ctrl+C 退出
    $ perf record -g
    
    # 查看报告
    $ perf report

    这样,你就可以看到下图这个性能报告:

    你看,stress 占了所有 CPU 时钟事件的 77%,而 stress  调用调用栈中比例最高的,是随机数生成函数 random(),看来它的确就是 CPU 使用率升高的元凶了。随后的优化就很简单了,只要修复权限问题,并减少或删除 stress 的调用,就可以减轻系统的 CPU 压力。 

     

    小结


    碰到常规问题无法解释的 CPU 使用率情况时,首先要想到有可能是短时应用导致的问题,比如有可能是下面这两种情况。

    • 第一,应用里直接调用了其他二进制程序,这些程序通常运行时间比较短,通过 top 等工具也不容易发现。
    • 第二,应用本身在不停地崩溃重启,而启动过程的资源初始化,很可能会占用相当多的 CPU。

    对于这类进程,我们可以用 pstree 或者 execsnoop 找到它们的父进程,再从父进程所在的应用入手,排查问题的根源。 

    更多相关内容
  • 有设备放在家里,要做一系列复杂的内网穿透,把内网暴露在公网环境中才能在外面登录设备 有设备放在公司,复杂的网络环境无法做到内网穿透 有设备放在用户厂房,无法控制网络条件,每次出问题都要上门服务 有大一堆...
  • 对谈嘉宾是内心十分丰富的宝藏姑娘,既有理想主义自我,又有务实主义才干,虽然只有2年产品工作经验,却保持极速成长,在看来有着多年老人般的成熟度和思维视野。我们探讨了关于做产品、职场、个人、理想、现实等...

    55ab2b9a06e7393f96baefda56a82ce5.png

    本期内容,是鹅厂10年产品人与2年优秀新人的深度对话。对谈嘉宾是内心十分丰富的宝藏姑娘,既有理想主义自我,又有务实主义才干,虽然只有2年产品工作经验,却保持极速成长,在我看来有着多年老人般的成熟度和思维视野。

    我们探讨了关于做产品、职场、个人、理想、现实等常使人内心翻涌的一系列话题,内容全程高能,收到了非常多同学的好评,表示对自己的职业成长很受益。

    信息量较大,可先收藏。

    e49a3f40f441477961b52c535fea24f9.png



    1、腾讯产培生的选择和选拔经历

    【Summer: 】

    互联网行业有句话,说腾讯的产品,阿里的运营,百度的技术,现在可能有字节的技术,不管这个传言到底是不是正确的。但我的经验,腾讯的产品人才培养机制还有文化,确实是非常不错的。每年有大量的,不管是校招还是社招的同学,都想进到腾讯从事产品经理,所以人才的竞争是非常激烈的。

    刚刚我说很敬佩的一点,就是一一其实是在产品经理生物链顶端出来的,经过了腾讯产培生这样一个选拔机制,听说有非常多的很优秀的毕业生,能够在基础校招获得不错的结果,但参加产培生,甚至第一轮没有通过。如果我要去参加也是很难通过的。

    所以就特别好奇这个机制到底是什么样的,当初为什么要做腾讯产培生这样一个选择?

    【一一: 】

    首先我的话,之前的经历比较杂,本科跟研究生的时候做过很多实习,包括偏科技公司的研究院以及像联合国这种非政府组织,甚至在一些创业类的公司,还有艺术咨询类的机构,都做过实习。

    但是最终的话,我觉得第一份工作的想象,应该能给我一个比较扎实的学习环境,能获得一个比较明确的成长预期。我参加校招之前,在腾讯做暑期实习,知道如果真的到了这样一个工作环境以全职身份加入的话,是怎样的情况。

    第二个就是这个项目很吸引我的,就是它有轮岗机制,再加上是跟一小撮人大家一起组成一个班级一样,会定期有培训,大家在组里面交流,有group的感觉,让我觉得会很有安全感吧。

    【Summer: 】

    讲讲当初都经历了什么,能从那么高的淘汰率走出来?

    【一一: 】

    首先,我觉得产培生它有一些倾向的候选人吧,比如大家可能学习会相对好些。然后,有想法,善于表达,它招了很多经历丰富,又比较有潜力的一些人。如果你有一个做产品经理的梦想,你的经历比较多元的话,或许比较适合你。

    准备建议,我觉得产培生适合对于产品经理感兴趣,但还没有非常明确我到底要在哪个赛道,它给你提供了一个探索途径。但它的轮岗机制也造成你在每个方向的探索,可能在某些人看来是不够深的。

    怎么更好的准备,我当时是把所有的实习经历,真的是写得非常清楚,就是我在做每一份实习的时候,不管是过程中还是实习之后,都会写一个非常详细的复盘。包括我做了什么事情,我得到了什么样的反馈,我从这个里面发现了什么,我觉得哪里还可以做改进等等,都要做一个非常明确的记录。

    就是说你对自己做的事情有一个很深刻的理解,这个时候,面试官不管问什么。你都能够非常有条理,能够讲清楚是说自己到底是怎么想的,把你的故事讲得比较好。这个其实是当时我受益比较大的一个点。

    还有一个点,我不太确定是不是有代表性啊,就对我来说比较危险的一环,就是群面,因为我我之前从来没有参加过群面,大概是十一/十二进一,在一个很混乱的环境里,每个人都想表达自己,你是不是足够冷静,是不是能够把问题的关键点出来,而不是说为了要有ownership,去强行输出观点和组织大家。

    【Summer: 】

    以前校招我们一天有时候要组织十来场群面,对于群面:

    第一个就是不要抢着争风头;第二个就是千万不要一句话不说,完全没有给自己亮相的机会;第三个就是不要为了说而说,就是你说了半天发现这个观点特别的浅显,或者你的逻辑思维特别不清晰。就尽可能为自己争取一个比较适当的机会,把你的东西带有一定深刻见解的方式表达出来,基本上这种反而容易通过。


    2、职业成长秘诀:Get hands dirty

    【Summer: 】

    原来我有一个担心,就是产培生都是精英同学,会眼高手低,会挑活,但我合作过产培生后,这个疑虑完全打消了,觉得你们是特别好的同学。

    我记得有一次,咱们开那个产品总结茶话会,让大家讲讲过去一年的想法收获。你当时就讲了一点,我到现在就印象特别深刻,你说开始工作的时候就给自己定了一个原则:一定要get hands dirty,我觉得对一个新人非常难得,能讲讲你当时怎么提出了这一点吗?

    【一一: 】

    这其实是我在毕业之前的时候,我在想,如果我对职场有什么预期的话,就是我要把手弄脏,因为我觉得我其实并不了解这个真实的商业社会是怎么运作的,也不了解当你去真的做一个业务到底意味着什么,你需要具备什么样的素质,怎么样能够把事做成。所以要获得这种真实的理解的话,就不能停留在自己的幻想里,就要真的扎到业务里面。

    一方面因为从自己角度来说,我一个非常目标导向或者想成事儿的人,只要我能把这个事情做成,只要我能对这个事情有充分的理解,我不介意我做什么,哪怕是最基础的事情我也做,我知道这个事情它是怎么work的。这个事情本身就是一种成就感,给我带来很大的满足。

    第二个点是说因为就我自己性格,是一个挺就是挺文艺的人。喜欢各种各样可能大家看起来比较稀奇古怪的东西的人,所以从小到大,我的家人,身边的朋友,都会形容我是一个很飘的人。这其实让我内心有种恐惧感,担心我的性格,让我变成一个对这个世界没有深刻理解的人,就沉浸在自己的小世界里面。所以我反而觉得进入职场对我来说是一个非常好的机会。

    你必须要打破幻想,要接触到这个事情到底是怎么样的。让你的那些观念接受锤打,你才能说这个观念是值得长期持有的观念。不然的话,你脑子里总是觉得很飘的观念,从来没有经历过挑战,你怎么知道这个东西到底是对的、是错的,它适不适合你。

    我进入职场之前,就希望自己能够被挑战,希望自己能够接住抛给我的任何的事情,在这个过程中去培养一个比较成熟的对事情的理解。所以我觉得get hands dirty就是一个非常重要、非常必要的一个手段吧,我从这个习惯里面收益非常多,让我变成了一个更成熟的人,变成了一个更能担事儿的人,是一个挺正的一个循环吧。


    3、职场中面临的困难,如何求解

    【Summer: 】

    在我们这的一年,你觉得对你的锤打,符合预期吗?

    【一一: 】

    说实话挺符合的。我来之前,对于真实的商业世界怎么运作是完全不了解的,再加上我之前从来不知道ToG的业务到底是怎么运作的,在这一年,一个是从事儿的角度,就是企业跟企业、跟政府之间是怎么样把一个事情推动落地的,觉得有很多超出我之前理解的逻辑。其实真实的世界是很复杂的,它不是那么规则清晰,边界明确。但可能这就是一个真实的商业社会的事情。

    第二个可能也是从人的角度,就是ToB也好,ToG也好,这种业务形式的决策链条很长,利益链条也很长,在这个过程中,会跟很多个角色打交道。比如说公司内的,什么商务同学啊,架构师啊,这些我们就都不说了。这种公司外的,比如说一些地方经销商啊,代理商啊,包括一些领导啊,学校师生啊之类的。

    对于人跟人之间的关系,人跟人之间怎么互动,或者是说各种力量关系之间怎么有一个微妙平衡,我不能说我理解了,我只能说意识到了他们的复杂性,以这种复杂的必要性,就是你想做成任何一个事情,其实他都是建立在你对于这种复杂性,首先你要体验过,然后体验过之后你要理解要学会跟它们共处,所以我觉得对事对人的这种复杂性的理解,是我第一年感受到了被锤打的地方吧。

    【Summer: 】

    还能想起你在这一年有什么困难的时候吗?

    【一一: 】

    困难的时候挺多的,首先我刚来的时候吧,可能有几个月还是没有找到自己的位置,那个时候确实很迷惑,就是在这样一个新业务,没有一个非常标准的成长路径。而且我那个时候其实有段时间比较恐慌,因为我身边可能其他的产培生在一个比较成熟的业务,他其实会有很明确的工作预期,说我要培养哪些技能,我通过做什么样的事情去培养这些技能,但于我来说不一样,就是我在一个非常新的业务里面。甚至这个业务对我的期望,到底是不是一个产品经理,还是需要我去承担更多职责,是等待我去探索或者说在跟这个环境互动过程中,去找到自己的位置的。

    所以前几个月其实就是属于一个比较迷茫的状态。再加上是职场第一年嘛,哪怕你进到一个非常成熟的业务,还是会有些适应性的问题。然后到了中期的时候,把这个事情去推动落地的过程中,就遇到前面说的这个商业社会的那种复杂问题。

    我为了想做成这件事情,需要暂时悬置自己的判断,不再去想说我是一个怎么样的人,或者是说我希望以怎样的方式做事情,而更多是说如果我想要做成这个事情,这个环境要求我用怎样的方式去应对,那个时候其实是一个比较痛苦的转变,因为你意识到可能这个职场或者说这个环境对你其实是有一个不一样的要求,这个要求可能跟你自己对自己的期待并不一样。然后你又有非常明确的想要把这个事情做成的欲望,所以,需要经历一个自我的转变吧。

    我知道有些人可能先天比较适应这样的环境,因为他的性格或成长经历的原因,但对于我来说,需要有一个调整过程的。我把自己调整为一个适合这个环境的一个人,但跟那些先天就适合这样环境的人比,我还是不够的,还是不足的,那我的竞争力到底是什么,我的核心到底是什么,那个时候就会比较迷茫这点。但是我觉得,如果想要做成那个事,我可以调整自己。

    还有就是我并没有得到想要得那么多资源,拿到那么好的机会把一个事情做得特别圆满,除了对自己之外,我对整个大环境也有了更多的认识,如果你要做成,不只需要你自己的努力,还需要机会,反正就意识到真的做成一个事是很复杂的。

    意识到这一点之后,我一个核心的疑问是,如果这样的话,那我在里面的位置到底是什么?这个事之所以能做成,可能也不是因为我,或者说我侥幸做成了,我也不可能把这个事情成功的原因归根于我。

    我是一个主体意识非常强的人,就是在做很多事情的时候,我都会不断地问自己,这个事情对我意味着什么,我到底怎么理解这个事情。所以后来找到一个点,就是说,不管是事情成或者不成,哪怕他不成,我知道他为什么没成。这种理解,是没有依附于这个大平台的,是我可以带走的东西,在这一年之中,我内心的起起伏伏,最终可能找到了一个自我的支点吧。

    【Summer: 】

    你这个剖析好像我们还没有这么深刻的讲过,以前工作的时候没有这样的机会这样聊天。

    我觉得刚刚讲的好多点,属于你自己,也属于非常多的人,它有几层东西。第一层,就是你跟他人的关系,比如说毕业生和刚进职场的新人,经常出现一种情况,就是大家会特别容易去看跟我同样水平的,或者跟我原来在同一个时空里的人,他们是一个什么样子,他们发展成什么样子。比方说我的同学,他去了哪些公司的什么业务,尤其是那种有名的业务,会觉得说他是不是发展的特别好,然后我是不是落后了。

    还有一种,你看别人都在做一些风口或者热门的东西,我做的东西是不是没有前途,这种东西特别容易引发焦虑,这是一个特别典型的问题,就是我们跟他人的关系。但是就像你说的,其实我们跟他人的关系,其实真的一点也不重要,看他人对我们自己一点帮助都没有,最后你都要回到自己。

    第二层就是我跟我到底是一个什么关系。你只有处理好我跟我的关系,所有其他的问题可能都会慢慢不存在了。这个我跟我的关系,就是经常会出现一种我预期的那个发展方式,跟实际发展方式,是岔路的时候,应该怎么办。比如我希望事儿做成什么样子,我的职业发展轨迹一步两步三步应该是什么样子,我希望我应该得到什么,结果是什么,想的特别明确,但你发现现实生活中,就是另外一条路,这个时候可能是怀疑自己,或者怀疑环境,就会卡在这儿。我觉得你是完全是把自己融入到新的路径里去了。

    第三层,就是自己跟环境的关系了,是最常见的一种关系,就像你说的,有时候觉得自己特别厉害,有时候觉得自己特别渺小,那当充满这种无力感的时候。我给自己设定的一个方式,就是说只要我在,那我保证我做的这个东西,我可控的部分,我一定保证他一百分的可控,那对于别人不可控的部分,就是我能控制多少就去控制多少,但实在控制不好的,觉得可能就只能是放手。

    【一一: 】

    对,有些东西是你要保持关注的,但那个东西很多是不可控的,你要从里面跳出来说哪些是我自己控制的,我会把它设成我自己的成长标尺,就当外界没有办法那么快给到一个反馈,或者这个反馈跟我自己的努力无法归因的时候,我会找到一个自己的标尺,就是当我达到一个什么样的水平,我觉得这个阶段的learning是ok的,或者我已经努力了,就可以了,这个点确实是让我的心态变好的一个很重要的一个原因吧。


    4、对自己负责,目标感与主观能动性

    【一一: 】

    我觉得做任何事情都是,作为一个成年人,你要充分意识到对你自己负责。对你的决策负责,当遇到什么事情的时候,首先要想我到底还能做什么?是不是有没拍死的东西是我可以去调整的,不管是调整我自己,还是调整这个环境。总而言之,必须是一个足够主动的人,足够主动的去雕琢你的工作边界。

    你应该也是一个目标感比较强的人,这种目标感不是说它的kpi,怎么样去衡量这个事情是否成功,而是你怎么定义你自己的成长,你到底是想收获什么,想要什么,它不是这个业务对外宣称的使命愿景,而是这个业务对你意味着什么。

    我觉得目标感跟主动其实是相辅相成的。

    【Summer: 】

    如果没有目标感,就一步一步,你被安排到某个事情上,目标就放在那儿,这个时候你就要按照被安排的方式去做,所以你不主动也可以,你就被动去做也可以。但其实就像你说的,如果一旦积极主动起来,你会发现你能掌控的东西,有可能它是可以被扩大的。它有可能处于可控跟不可控之间,当你主动一些的时候,会更容易把那个界限往外扩一扩,把它变成你自己可控的部分。

    其实工作中有非常多这样的细节。有的人可能就觉得差不多这样,也符合预期就ok了。但如果你的责任心到了那个程度,或者说自己的主观能动性,到了那个程度之后,你能抓住更多的机会,那个机会,真的是你抓来的不是别人给你的,有时候别人都没意识到。

    【一一: 】

    讲一个蛮有趣的事儿,就是我一个同级生吧,大家一起聊天,他看到网上有人在评价他之前在的那个业务,就说这个业务很差,团队很差,各种吧,然后他当时就很疑惑,他说这个跟他当时在的体验完全不同,他就非常困惑,为什么大家觉得很差的事情,他自己好像当时在里面还学到挺多,成长挺多。我觉得这个可能也跟我自己的想法挺一样的,哪怕大家都在做着同样的事情,在同样的团队里,每天面对同样的人,但两个人的收获可能完全不同。

    我特别喜欢一本书,就是《禅与摩托车维修艺术》,有提到说一个专家跟一个新手的区别,就当你真的用心投注在一个事情上面,不管是从你自己角度,还是从别人的角度,你是真的能够感觉到那种区别,就是有没有用心做这个事,有没有一种目标感。

    它不只反映在一个外在的反馈上,因为很多时候外在反馈是延时的,或者说没有那么全面,但你自己会很清楚地知道,当我用心在做这件事情,和我只是为了交差去做一件事情,体验跟收获是完全不同了。


    5、产品经理和产品经理很不同

    【一一: 】

    产品经理跟产品经理真的差别很大,工作界面的变化,每天要做什么样的决策,要跟什么样的人打交道等。我觉得产品经理要成长的话,是通过一个又一个的决策喂出来的,通过做一个决策,得到反馈,从里面获得一些成长,然后知道以后该怎么样去处理。

    还有环境到底要求你扮演一个什么角色,真的是差别很大。比如我第一年,其实是在跟着商务同学在外面跑,会跟很多公司外的人打交道。但我现在的话,更加偏后端一点,跟内部的一些研发算法,一些共线的同学打交道。在这个过程中,你就发现不同角色,所适应的沟通方式、工作习惯、合作风格都是不一样的,你需要知道怎么样去把这个事情做成,怎么样去表达,自己在里面是什么样的位置等。

    【Summer: 】

    对可能想要转行的同学,也挺有借鉴意义的。因为现在好多人都挺想脱离原来自己的行业领域,尝试一个新领域,但因为新领域没经验没接触过,他对新领域有完全正向的一种期待。但我们知道,任何一个领域一定有它的是两面性,有它正向的部分,跟它非常现实的地方。

    我觉得像你刚刚说的,这个过程中,除了get hands dirty这个原则,第二个我觉得就像水一样融入一个地方。

    没有给自己画圆还是画方,让自己渗透到任何一个环境的那个形状里去。对于转行业或者转环境的人来说,尤其需要这样,可能你要放弃原来的那个形状。不是说让你完全放下自己,不做自己,而是说在一开始的时候,可能要把自己先打碎变成水,去那个环境,先进去了解,渗透到所有的边边角角里去。你熟悉了这个新的环境,它的玩法、它的规则你才能知道啊。

    【一一: 】

    当切换环境的时候,先放弃那么多自我的判断吧,先说有什么可取的地方,有什么是我可以学习的,还挺重要的。

    你对自己是有期待的,外人对你也有期待,但可能短期内达不到这样期待的时候,会是一个挺难受的状态,我觉得这个心理准备要做好。


    6、环境切换后的底层意识

    【Summer: 】

    那你觉得从第一年里带走了哪些可迁移的部分到新地方。

    【一一: 】

    我想起来前段时间跟我组长聊天时候,他跟我说,因为我第一年是在做ToG业务,其实跟第二年业务完全不相关。他们面候选人的时候,之前做商业化或者广告相关的业务其实更匹配。但当时面完我之后就没有再面其他人了,他就说,其实是在我身上看到那种意识,就是想把事情做成,很有目标感,有比较好的反思意识,我觉得是这些更基础的技能吧,这是一个点。

    第二个点就是,因为第一年是做偏行业的事情,我有更多行业的视角。如果做策略产品,大家会更加偏向像数字游戏一样,什么机器资源啊,动态算力啊,这些就很技术,但因为我第一年对行业的事情有些关注,比较看重面临的行业趋势到底是怎样的,面临什么样的挑战,这些东西帮我在工作的时候,有一种更好的语言去跟运营,跟更前线的同事打交道。

    【Summer: 】

    第一点我特别赞同,虽然说产品隔行如隔山,但是你真正想要把一个事情,任何一个领域,把那个产品做好,你底层的那些东西是底座一样,能支持你,走得更远一点,做得更好一点。

    第二点像你说的owner意识一定非常重要,我觉得接触过的做得好的同学,owner意识都是非常好的。

    另外就是行业,这一点我感受挺深的,比如团队来了新人,第一件事让他做的就是行业分析,包括政策的理解,行业生态的理解,即使前面有同学已经做了特别好的材料,也不希望你去学习别人做的材料,而是说这个事情你要从不会到会,必须亲自去做,做完之后,你再去看看别人做的是怎样的,吸取一些更好的东西形成自己的,这个可能是行业产品的优势,先天会对这些东西比较敏感。

    【一一: 】

    其实我还蛮喜欢这个过程的,让我意识到做业务是足够复杂的,有很丰富的层次的。我觉得要比做一个纯粹的功能有意思,你能了解到这个业务有很多面,它是依附在一个什么样的政策环境里面。


    7、成长沉淀的正循环

    【Summer: 】

    你现在还写公众号吗?

    【一一: 】

    我现在经常在即刻上发点东西,也有一些关注者吧,但我那个东西完全跟工作不相关了,就是一些比较琐碎的自己的感受。

    没有写公众号的原因,是因为如果我去写公众号的话,希望是说我对这个事情有一个比较全面的理解,一旦开始写,可能就会是一个比较长的篇幅,不会是像类似于周期一样,这周有什么新题,下周有什么新题,我觉得那个东西可能不用放在公众号里,随便发在一个别的什么地方也都ok。

    另外就是,我确实觉得在广告或商业化业务,见到了挺多优秀的人,这让我觉得很有敬畏心,我觉得如果要写的话,我想发出来的声音是什么,这个事情现在还没有想的特别好,但其实我一直会有输出的习惯。

    【Summer: 】

    对,这点我也特别赞同,如果我写的东西没有自己的视角跟深刻的理解,写出来没有对至少一部分人有价值的话,就很难动笔。

    很优秀的新同学,觉得他们有什么特点?

    【一一: 】

    一些很优秀的同学,很愿意帮别人解决问题的,而且他不会觉得这是一个很苦的事情,他会觉得,哎,我又学到了很多,不介意去做那些看起来比较苦、比较累的活。而这些部分往往覆盖着一些新的价值,然后在这个过程中形成自己的见解。

    另外我觉得他们都有一个很好的工作习惯,就是怎么去在内部塑造你的影响力,经常会做一些输出或者沉淀,会让更多人意识到你是一个很专业的人,是一个值得信赖的人,当他们遇到问题的时候,也会来找你,形成一个正循环。


    8、职场之外的独立自我

    【Summer: 】

    咱们现在讲了好多产品啊,市场啊,前面我说很佩服一一的一个点,就是职场这个角色之外,一一有另外一面,你有一颗特别文艺的心,现在还在追求这些吗?

    【一一: 】

    嗯,有的。

    前段时间有一个电影很火,叫什么花树,一般恋爱还是什么,是一个日本电影。讲的就是很两个很文艺的男青年,女青年,他们相爱了,但他们后面成为社畜之后,慢慢各自发生了变化,最终分开的一个故事,很多人觉得很惋惜,两个灵魂百分百契合的人为什么最终没有走到一起,被现实磨灭了。

    我以为我看这个电影会很受触动,因为里面描述的那个男女主角的形象,觉得跟我非常像,也是一个非常喜欢各种文艺东西的人,但为什么我并没有被那个电影打动,因为我觉得在工作一年多之后,开始意识到我不能让996的生活变成我的全部,磨灭了我可能我生活以外的一面,或者说我本来是一个非常复杂立体的人,然后因为工作,变成了一个非常胆小的一个人。

    我不会觉得因为工作,我的另一面被压制了,我反而觉得,因为工作,我对存在另一面,这件事情更加珍惜了,意识到,它对我来说非常重要,不可或缺,且我有义务不怨天尤人,而是保护好我自己的这一面。

    我不会觉得必须要找一个特别清闲的工作,如果没有时间做想做的事情,每天都是打工人,非常惨,我不会这样想,我现在更多是说,如果想保留我的这一面,我要照顾好我自己。

    我观察到,身边有很多人,有很多优秀的人在工作上,都是很善于自我剥削的人。在大厂这样的工作压力下,大家会不由自主的去自我剥削,而且更加可怕的是,把这种自我剥削内在化了。会觉得我需要让我的每一份每一秒都是能够创造生产价值的,要每天想要怎么搞钱,要怎么更好的晋升等等。你看不到,其实你有另外的可能。

    我会对这个事情尤其的警惕,会觉得不要因为我是一个有目标感的人,因为我是一个想成事的人,所以我被拿捏了,我所有的时间都要去想这一件事情,其实不是的。反而当我有一个自己独立世界的时候,我把自己的内心照顾得更好,那当我回到职场上的时候,其实我是一个更平静,更从容的状态。

    【Summer: 】

    我听着特别感动,虽然我们年龄跨度非常大,但是现在听你讲这些话,觉得特别重要。如果早一点能有人这样去告诉我,就非常开心,一路走来,没有人告诉我这些,然后就像你说的,自我剥削反而成为一种正确的事,但是我觉得一定要醒过来,找到另外一种更加内在的,那个自己的部分,想办法去保护。

    对,希望有更多的人能够这么做吧。

    ↘好文推荐:

    【万字干货】产业互联网B端产品经理实操手册
    【产品经理求职攻略】10年产品人经验分享
    凯文·凯利:下一个5000天的12个必然趋势!

    👇欢迎关注:

    0d21d386dc4c9750e488bd322e0aff72.gif点个“在看”

    展开全文
  • 浅谈PM(项目管理)

    千次阅读 2014-10-19 20:28:43
    浅谈PM(项目管理) (2009-04-22 20:44:34) 转载▼ 标签: 项目管理 风险 软件开发 满意度 it 分类: Erp项目管理 一.商务谈判   1.作人的姿态 作人似乎跟商务谈判不...

    浅谈PM(项目管理)

    (2009-04-22 20:44:34)
    一.商务谈判

     

    1.作人的姿态
    作人似乎跟商务谈判不太有关系,很多技术人员相信PM需要的是本事,是如何做好一个项目,而不是会搞好关系弄的四平八稳的人。随着PM在中国的悄悄兴起,越来越多的PM开始在老总的授意下参与商务谈判,和销售们一起打单子,这就比较实在的需要PM们去揣摩客户的心理。揣摩客户心理需要有多方面的知识,需要深度和广度,然而,最重要的仍然是作人。如何放下架子,降低作人的姿态,对从技术人员转型的PM们来说,是至关重要的。

    降低作人的姿态需要从多个方面去实施,最主要应该记住:人不可貌相,更不可以地位衡量。很多公司为了保持公司形象,会统一叫员工打扮的好看一点,看起来象个白领的样子。然而,老板多半是没有约束的。中国改革开放才二十年,很多有钱的老板实业家文化层次都不高,往往是当大学生们只会把屁股坐在板凳上肆意挥霍父母辛苦积攒的财富时,他们已经在各地奔波,积累丰富的商业经验并对金钱,人生和社会的本质有了充分的认识,形成了自己稳定的思维框架。这些人,很多都是穿着旧旧的衣服,戴着破破的手表,说话的时候经常会带上三字经,钻进上海的人堆里,搞不好你会把他当成民工。因为到他们所处的社会地位,已经不需要任何华丽的外表来衬托自己的身份,他们有的是底气。对PM来说,这是个非常危险的挑战。虽然说项目在初期有意向时会对对方的人事和关键人物有一定的了解,然而大项目里能说的上话的人太多了。上海人最瞧不起的就是土气,很多人谈项目的时候看到民工或很俗气的表现不免会皱皱眉头,往往在皱眉头的时候就失去了项目,也就是失去了市场和金钱。PM必须作到能与每一个层次的人交谈,尤其是看起来比自己层次要低的群体,哪怕是公司里扫地的阿姨。只有作到谦虚谨慎,不摆架子,尊重别人,才会得到别人的尊重,才有机会赢得项目。鼻子比眼睛高的人只会把自己的鼻子撞扁。

    2.丰富的知识面
    光尊重别人还不足以赢得项目,准确的说是赢得对方关键人物的信赖。PM一般用不着陪客户喝酒吃饭,那是销售们的事情,但是PM和客户讨论问题可能是最多的。讨论问题的时候就是机会,如何投其所好,是一大关键。金钱与美女依然是常规的敲门砖,然而这种傻瓜也知道的办法人人都会去做。老板的关系也只是一个方面,如今的大老板,哪个没有关系?同等条件下PM凭什么去胜过别人一筹?

    我一个朋友(PM)打一个单子时,发现对方对什么都不太感兴趣,费了很大力气也找不到突破口。对方这个人非常顺利,金钱地位美女样样不缺。他花了好多天和对方交谈,以自己的博学逐渐取得了对方的信任。后来他隐约发现对方对数学和天文学的发展史有所涉猎,如获至宝,回家花一个通宵的时间在网络上搜索相关资料。第二天他根本不谈项目的事情,只跟对方大谈特谈哥白尼,布鲁诺,伽利略这些人的生平,整整吹了一天。对方点头如捣蒜泥,态度和热情都来个一百八十度转弯,隔天他就拿到了单子。这是个经典的战例,谁能事先想到哥白尼会来帮助IT的人赚钱?这个PM靠的就是博学和由博学引申出的敏锐的感觉抓住了机会,让客户产生共鸣。客户感觉他层次也很高,而且和自己有共通之处,信任度大大增强,把项目交给他放心。如今这种例子在商务谈判中已经屡见不鲜了。对PM来说,并不要求在各个方面都很精通,那是不可能的事情,只要PM对一些流行的话题和天文地理历史各方面的知识有个大概的了解,在需要的时候能尽快的掌握,才有机会创造机遇和把握机遇。

    3.强大的沟通能力
    胸中有万千墨水却不知如何表达其实是比较少见的,但并非绝对没有。每个人的人生轨迹都有所不同,思维受环境的影响也各有差异。包括象我们目前这个班级里的一些未来的MSE们,一定有比较内向或者不太爱表达自己观点的人,这些人比较被动,往往很难承担起谈判的重任。从今天开始,这类人就必须重新学习如何说话,如何大声的争论。沟通,并不仅仅是大声说话,而是在表达自己观点的同时发现问题并综合整理加以解决。除此之外,沟通的能力与社会经验息息相关,与PM的见识联系紧密。在日常生活中,PM就要多留心,多思考,当别人想到某个层次的时候要争取比别人考虑的更深。当然,也有一些不够踏实的朋友把沟通和吹牛当成了完全的一回事情,在和客户交流的时候口若悬河的说一些不着边际的话。这种人,碰到不懂,不太认真或者好奇心强的客户是有一定市场的;而有水平,负责任的客户往往会觉得这种人不可靠,一般不会把单子交给他。PM需要把握好这个度,吹是肯定要吹的,只是吹牛的时候一定要有基础的去吹,对从来没涉及过的领域或者根本不懂的东西轻易不要发表意见,挑选自己熟悉的方向合理的进行发挥,适当的留上一两手,给对方高深莫测的感觉,效果最好。

    4.优秀的售前团队
    这个团队一般是由总经理发起并组建的,通常不指定PMP,对团队的成员如SALES,PM,SA,ENGINEER们的团队合作提出了比较高的要求。一般公司在接下一个单子进行到一定程度的时候,PM往往会尴尬的发现协议上销售代表们对客户的一些承诺是几乎做不到或者根本做不到的事情。这种情况非常多,销售的任务是拿下单子,我听到的销售们说的最多的就是“没问题”或者“NO PROBLEM”,但是当我听到客户的要求和销售的回答时我总是心惊肉跳,很不自然。销售是非常辛苦的,为了建立客户关系,尤其是空白的市场是很不容易的,往往为了一个单子会牺牲非常多。在这种情况下,和销售进行协调自然而然的又落到了PM的头上。在销售和客户做承诺之前,PM要主动的跟销售交流,提供粗略的总体设计框架和技术难关以及能考虑出的工作量,而不是等出了问题再被动和销售在老板面前互相推委责任。在组建团队的时候,PM要根据团队里每个人的素质和任务进行因人置宜的信息传递。优秀的售前团队合作是接单的重要保障。

    在商务谈判的实际操作中,存在着各式各样的问题,PM的职责和要求绝非以上几点所能描述详尽。根据环境,政策,人文,关系等各方面的不同情况,PM的不同成长经历,每个PM最终都会建立自己对商务谈判的看法和经验。但是有一点可以肯定,这是PM成为PM的第一道关,也是最重要的一关。接不到单子,PM将失去存在的意义。与销售有所不同,PM在该阶段的任务除了接单,还要尽可能的搜集客户关键人物的资料并与对方各个阶层的负责人建立良好的客户关系,以便在项目实施时充分调动资源。

    二.启动阶段

    1.项目的一些基本概念
    项目三要素有多种版本,各不相同。实际操作中多分为范围,成本与进度,其中最重要的莫过于范围。我们把项目最终生成并提交给用户的产品和文档统称为递交件。谈判的时候一定要确立递交件的标准和要求,也就是范围。尽管商战的时候不可避免的客户会不断提高标准和要求,而承诺的款项却不会有一分钱的增加。但是这个标准对每个公司来说都有一个底线,一旦超过了这个底线,那项目就肯定是亏的。除非是为了二期有利可图或者是为了搞好关系,否则范围超过底线的时候情愿不做,再厉害的PM在这种情况下也是无能为力。建立范围需要的就是PM的多年的实战经验,在大大小小的项目中用血泪换来的一些体会。在这个时候,很能体现PM与技术人员的区别。成本就是客户答应付的款项,与我们的投入成本并不是一回事情。进度就不用多描述了。

    项目如何成功?也有一些关键的因素。个人的理解也不尽相同,通常包括以下几个方面:界定工作目标及工作任务;老板或高层的支持;优秀的PM和开发团队;充足的资源;良好的沟通;对客户的积极反应以及适当的监控和反馈。这里要注意的就是资源和高层的支持。一个上规模的公司总是同时会有很多项目,可是再大规模的公司资源也不足以保证每个项目都能组建最合适的开发队伍或拥有最好的环境。这时候各个团队或者部门之间不可避免的会发生资源争夺战,摩擦再所难免。这时候对PM的作人再次提出挑战。除了高层对PM项目的重视程度,如果PM平时在公司与同事相处的好往往能使很多别人看起来很棘手的问题迎刃而解。相反,一个不会作人的PM由于人缘差,即使高层强压别的部门或团队配合,别人也会能拖就拖,延缓项目的进度和质量。有时候,这种内耗对项目和PM来说是毁灭性的。对客户的积极反应也比较关键。一般来说PM已经被项目里大大小小的事情搞的筋疲力尽,要PM去主动要求客户配合是很吃力的事情。然而,这个时候,越是困难,越是觉得累,越是要去主动。客户往往也不是特别的积极,主动与客户联系沟通和测试能及早发现问题。从风险控制的角度来说,问题发现的越早,风险越小,损失也就越小。积极的态度可以带动客户的积极性,在项目完工的时候,客户对你的感激往往是难以用语言描述的,这对以后接单或者做二期三期会打下良好的基础。因为在和别的新客户谈判的时候,新客户自然会找你的老客户了解情况,这时老客户随意的一句话顶的上你很费心的十句。

    项目具有商业行为的几个重要特征,有消费源,有参与者,有成功关键因素,有财务目标,有风险。

    2.启动阶段的主要任务
    根据PMI的解释,接单之后项目自然转入启动阶段。启动阶段PM的主要任务是率领总体架构设计师和系统分析员收集尽可能详细的数据,确立尽可能详细的需求,进一步确立详细的项目范围,预估资源,确立其他方案并获得进入下一阶段的批准。在这个阶段,随着需求分析的深入,PM也开始在公司内部进行人员挑选和资源争夺,着手组建自己的项目团队。项目即将进入计划阶段。
    在收集完数据之后,PM要和客户开始明确项目的大小,成本,规格,期限等重要特征并将其写入合同文本,同时准备内部的包括预算,衡量标准等文档,建立项目的评估标准。接下来就是需求分析。由于专业的原因,我们这里仅讨论软件工程项目的需求分析(以下简称需求分析)。

    需求分析的主要参与人员有PM,总体架构设计师,系统分析员,熟悉业务流程的客户。PM统领的团队这时候还不是真正的开发团队,我们叫做前期团队。随着需求分析的逐步深入,新的团队成员不断加入,启动阶段结束的时候正式的团队将建立。对一个已经启动的项目来说,需求分析直接决定了项目的成功与失败。最初的需求体现在客户的工作说明书或招标文件及附件上。这种需求一般比较含糊,无法体现客户真正的需求。前期团队要根据自己的经验和客户沟通并引导客户进入正轨。有时候客户会很不讲道理或者思路僵化,就要求按照他的思维去定一些明显错误的需求。这个时候团队成员要耐心和客户举事实,谈经验,讲道理,用图形或模型等直观的方式将需求描述出来,比如常见的数据流图等。所以说,争论再所难免,客户有时候会吹胡子瞪眼睛拍桌子甚至会说“这个东西不要你们做了”之类的话。PM此时除了要亲身参与需求分析综合整理文档之外,还要处理好团队成员与客户的关系,确保关系不会恶化到无法收拾的地步。只要PM尽力约束团队中的成员,这个度还是很容易控制的。

    对快速开发和叠代开发来说,需求和实现往往是同步进行,开发速度快是一大优势。对有相同或类似模式的小项目来说采用快速开发或叠代开发是很合算的做法,时下流行的极限编程就是针对这方面建立的思维模式。然而,大中型项目中有太多不一样的需求和模块。如果不是因为项目有差异,那么市场上就只有产品而没有项目了。所以,大中型项目的需求要认真仔细的去做。我们要讨论一个问题,究竟应该在需求分析和总体设计上花费多少时间?我们熟悉的瀑布开发模式基本上分需求分析,总体设计,软件开发,测试等几个阶段,然而究竟应该在前两个阶段上花多少时间却没有定论。实际项目操作的例子表明,分析设计的时间越长,需求设计做的越详细,测试的时间就越短,返工率越低,风险也越小,成本越容易得到控制。而需求分析和总体设计没有做好就急忙上马进行开发的项目在项目初期进展顺利的时候问题不大,到了项目后期和测试阶段一些潜伏期比较长但是破坏作用比较大的问题就会凸显出来,造成返工,延长测试时间。所以与其把问题堆积到紧张的项目后期,不如把时间多花点到需求分析和总体设计上。基础夯实了,金字塔就容易造了。

    在日本公司打工的程序员们可能都知道,小日本的软件规范非常厉害,他们花在需求分析和总体设计上的时间通常在40%到50%左右,远远超过国内软件项目的实施,效果也要强的多。他们总体设计的规范甚至详尽到某个过程该如何判断,确立什么样的条件,换言之就是把什么时候该如何写 (if...else)语句都帮程序员定好了。在这样的软件规范下,程序员更象是装配流水线上的工人,对一个模块或技术熟悉到一定程序就变成了完全的重复性劳动。所以在日本和欧美经常会有程序员是低级工作一说,很多人不明就里,对国内程序员也照搬,对国内的程序员来说是很不公平的。在国内,只会照抄别人代码,一点都不懂创新,凡事依靠别人,快下班就盯着表看的程序员是不少,这种人一般很难有什么前途。但是,优秀的不断进取的程序员也很多。由于国内没有象CMM这样的软件规范或者很少,所以这类优秀的程序员不少都是干着系统分析员甚至PM的活,拿着程序员的工资。这类程序员虽然在起步时会吃很多亏,而且是主动找亏吃,然而几年之后与前一种程序员的社会地位会出现明显的分化。当上进的程序员们作为PM进行商务谈判的时候,前者还在各个公司里频繁跳槽,跳来跳去都不满意。有些扯开了,回到我们的话题。日本的软件规范与CMM有惊人的相似,其中至少有35%以上都是几乎一模一样的。最近经济不景气,东京倒闭了160家软件公司,这个数字是今年6月份的,还在不断增加。这些公司纷纷抢滩上海,招收技术人员。如果去这样的公司应聘就要考虑清楚了,进去可以学到他们的规范和质量控制,可是要想从程序员成为系统分析员或PM,比登天还难。往往一个程序员进去干了好几年,对自己的那一块熟的不得了,而对隔壁同事所做的东西一窍不通。拒传华为正在尝试CMM4(华为印度研究所已经通过CMM4),对在华为工作的程序员们来说可谓福祸难料。当然,已经作到PM或QA或者热爱CODING的朋友例外。
    需求分析本身也存在着时间分配的问题。第一遍需求分析花的时间会最长,分析员们在客户的各个部门之间几乎把腿都跑断,把口水说干,就是为了确立一个初期的需求模型。所有的文档将会提交给PM进行复审并签字,不合格的打回重做。反馈表随之将提交给客户,第二遍第三遍等等等等接踵而来,与客户反复讨论和磋商,反复提交文档和表格,目的只有一个,明确需求。当PM最终合并了所有文档并确立需求之后,最终生成的需求文档将提交给客户的各部门负责人签字。这些文档将作为合同的附件添加,以便在将来项目变更或者碰到重大问题时和客户扯皮的重要依据。需要说明的是,客户并非都是蛮不讲理,但是说实话,颇有无奈,国内目前的项目大多数客户为了不让自己的钱白花,经常变着法子提需求。在启动阶段明确需求并签字,无论最终情况如何,一份详尽的书面文档可以解决很多口头承诺或概念模糊的文档带来的许多问题。

    详尽的需求分析有一个额外的好处就是对一些双方都很陌生或者从来无人尝试的领域将是一个决定是否进行项目的判断标准。有时候,这种大项目在签单时双方都没有绝对把握保证可以出成果,一旦在需求分析阶段发现难以逾越的技术难关,就会放弃项目。典型的例子就是NMD洲际导弹防御系统。上世纪八十年代初美国搞星球大战计划,拖跨了苏联。大家对那段历史有些含糊,很多人认为苏联人上了美国的当。其实并不完全如此,苏联人的情报机构无孔不入,并非那么容易上当受骗。实际上当时美国国防部已经开始着手NMD系统软件的需求分析,前后耗资数亿美圆,耗时两年,仅仅是做需求分析,终于发现存在着在当时技术上无法达到的高度,随后项目被放弃。

    3.项目启动
    项目启动要确定项目计划,与客户一起实施第一次项目审核,确认并对一些产品和服务向下包厂商下订单。这个时候的PM会忽然发现有开不完的会,一天开三到四个会议是很正常的事情。这些会议有与客户的会议,与下包厂商的,有团队的,有公司高层的。团队的会议主要是建立正式的团队,提供团队成员的角色和职责,提供绩效管理方法,向成员提供项目范围和目标。与客户的一个主要会议将是项目启动会议。在这个会议上PM会与客户确立正式的交流渠道,项目综合描述,让项目参与人员相互了解,建立以PM为核心的管理制度。还有一些零零碎碎的东西甚至包括办公场地的大小,电话多少部,所有人的联系方式等等都要在会议上确立,并做会议记录。这都是些非常琐碎的事情,听起来婆婆***,却是非常必要,缺一不可。大概就是所谓三军未动,粮草先行吧。
    这时候,作为公司高层,应该向全公司发表申明,正式给PM发布项目经理任命书和项目授权书。这个动作虽然在别人看来有些形式主义,但是对提高 PM本人的士气和责任感是有很大助力的。

    三.计划阶段

    1.定义结构分工结构图(WBS)
    启动阶段结束后,项目进入计划阶段,也就正式进入实施。这里概念可能有些不太对头,其实是翻译的缘故,反正大家明白意思就行,不用拘泥于字面。WBS是一组要提交的项目元素,用来组织定义项目的总体范围,具体包括从工作内容,资源,成本角度考虑项目范围;建立一套系统所需要的分层工作结构;把项目分解成易于管理的几个细目,这概念有些模糊,其实跟资源管理器里分目录是一回事情。可以说,WBS是计划阶段的核心。WBS会详细的分到递交件,包括给自己人用的项目使用的过程文件,给客户用的模块和说明文档,完成每个细目的标准以及如何把这些细目的责任分配到具体的个人。WBS有缩进式和树状式,我这里也没办法画图,大家参考一些项目管理的书籍,里面有详细介绍。我整个文章只挑我觉得需要注意的地方,如非必要,对技术细节或者工具使用不做详细介绍。WBS的细目并不需要分解到同一水平,最下面的细目叫做工作包,分包的依据是个人的责任和可信度,也就是说到每个人头上的任务是否能落实,是否有把握完成;还有就是准备对项目进行控制的程度,程度越深,WBS树也就越深。由于WBS是实用性的东西,根据个人理解也不一样,所以一个项目可能会有几个正确的WBS,看PM的需要和最适合当前团队状态的进行选择。

    WBS的定义还是很麻烦的。PM要召开团队进行讨论,向成员提供与项目相关的所有详细资料,并把WBS树分解到二层三层。然后要花上一段时间让成员进行头脑风暴式(BRAINING STORM)思考,制订工作产出和相应人员的职责,记录每一个工作包的完成标准。在头脑风暴式思考时,会有很激烈的争论,PM要协调关系,调节气氛,从自己能考虑到的各个角度旁推侧敲,提示成员的思维角度和方向并加以总结。尽管很麻烦,制订WBS仍然是非常值得的。如同需求分析一样,WBS准备的越充分,编码的进度越快。

    2.风险管理
    既然是商业行为,那么项目的风险必然存在,相信阅读这个帖子的朋友不少人都经历过或大或小的风险。有些风险很容易解决,有些风险则大大损害利益。不论什么样的风险,能避免尽量避免,所以有必要对风险进行管理。由于风险的不可预知性,风险管理难度很大,概念也很难讲清楚,只能从一些可行的角度去分析,进行管理。

    首先要识别风险。这是个难度很高的活。PM要先召开风险识别会议,这个会议面向公司,高层,跨部门的有经验的人都将参加。然后审核由项目小组生成的风险清单并与重要成员进行风险沟通,检查一些重要的风险源如WBS,成本(时间)预估,人员计划,采购管理等等。最后就要用到PM本身在以前类似项目中得到的经验教训。

    识别之后要进行分析。我们可以进行粗略的量化分析(精确分析是不可能的事情)。有经验的人可以一起参加讨论,把提交出来的风险进行分类。首先按发生的可能性分,一般分成高,中,低三个级别,虽然很勉强,但是好歹也有个量化了;然后按耗去的成本分,也是高,中,低三级。我们可以把这两种类别的三个级别进行组合,碰到可能性也高,成本也高的风险就定位为不能接受。碰到这种风险只好让客户修改需求或者增加风险预留成本,否则一旦亏起来不是亏一点点,有可能赔的很厉害。高和中,中和中的搭配都是属于高风险,中和低,低和低搭配属于低,高和低搭配属于中。

    针对出现的可能性,需要采取一些手段降低风险。到目前为止也没有一个定论说有绝对好的方式,只能尽其所能的避免。有几种方法可以考虑,第一种是将风险纳入项目管理计划并指定负责人,由外部人员定期检查项目风险,一旦风险发生,执行风险管理计划;第二种是保险,这种属于风险转嫁;第三种方式有点奸,不过最保险,就是把客户拖下水,让他们一起参与风险管理,呵呵,到时候就好说话了:)
    风险管理作为项目计划之后,PM需要更新WBS,修改日程计划和更新风险管理计划。
    风险预留通常是成本的8%。

    3.预估
    预估是从量化的角度对项目进行评估,主要包括工作量,任务期限,人力,设备,材料,成本等,要注意预估不是财务策略或报价。
    预估其实并不是一次性工作,在整个项目过程中,预估始终需要。预估似乎没什么特别需要提的地方,每个PM接到项目的时候自然会有预估,在项目发生变更或进入下一阶段时也会预估。预估的作用主要还是让PM作到心中有个底,安排计划时不至于毫无头绪。

    4.进度计划
    进度计划就是一个模块或功能要写多长时间,PM安排个日期,设立里程碑,叫程序员们不能偷懒。进度计划是从WBS提取过来的。对PM来说,合理的安排进度计划对项目控制和激励团队士气有着很大的作用。对程序员来说,进度计划毫无疑问是噩梦。

    显示进度计划一般有先后顺序图,甘特图和里程碑图表。上回邵卫老师讲课,推荐的工具是m$的PROJECT,这个工具我还不会用,因为没时间去摸索。我的头倒是用的很溜了,近一个月来他就用这个PROJECT画了一个又一个的里程碑图,不停的折磨我和同事的神经。我们一般都是一边开发一边做UNIT TEST,效果上来看,因为有强大的时间压力,效率上比之前确实要提高不少,可是我们也只能结结巴巴的赶完进度。由于TEAM里人少,我们都是一个人做几个人的活。我每天早晨六点多出门,经过将近两小时颠簸,八点多点已经坐在位子上,中午吃15分钟的饭,干到晚上八点下班,到家吃完饭往往已经11点了。一个多月我从来没吃过早饭,没有睡过六个小时以上的懒觉。虽然强大的压力使我们能在短时间内掌握尽可能多的技能,开发更多的模块,但是对我们的情绪也是有很大的影响。所以说,项目里程碑是一把双刃剑,合理安排才能既促进效率也不至于打击士气。团队成员士气的逐级衰落会给项目后期的开发带来难以估计的影响,进度将会大大延缓。关于PM和团队的问题我们后面会讲到,这里我先祥林嫂一把,然后跳过。

    里程碑图表的特征是任务,成员和时间,任务和成员用文字标志,时间用数字描述并辅助以图线跨度,象阶梯一样非常形象,一目了然。管理起来非常方便,完了的打个钩就可以了。

    网络逻辑图是表示任务和逻辑关系的示意图,可以用先后次序表示,也可以用关键路径表示。其实把各个活动划分为1,2,3,4等阶段,每个阶段包括小活动1.1,1.2,2.1,2.2,2.3,2.4,3.1,3.2,3.3,4.1,4.2等,日程计划也分四种,一般只提到从前向后和从后向前两种。从前向后的概念就是某项活动必须相同或晚于直接指向这项活动的的所有活动的最早结束时间的最晚时间。有些绕口,我们打个比方:2阶段指向3阶段,那么2阶段里的4个子阶段也都指向3。假设2.1结束时间为1月12日,2.2结束时间为1月22日,2.3结束时间为1月15日,2.4结束时间为1月20日,那么,2阶段中最晚的结束时间是2.2的1月22日,所以在3阶段中的3个子阶段3.1,3.2,3.3的最早开始时间都不能早于1月22日。至于从后向前的例子大家自己去推吧,我就不举了,刚才几个123打的我累死了:)

    项目经常需要调整进度。在不改变项目范围的情况下,调整进度有几种方法:利用快速跟踪手段来改变任务间的关系;将串行的任务改成并行;改变工作方法(可能改变WBS);改变日期限制,使关键路径上的任务开始或结束的更早。虽然方法多样化,在我看来只有一条,就是拼命的压榨程序员的劳动力。如何压榨,还是个技巧。如前面所分析的,需求分析恨不得多分点时间给它,压需求是不太可能;测试阶段后期接近完工,罗里巴唆的事情一大堆,忙都忙不完,那时候PM一门心思提前/按时完工,好收钱,压那段时间似乎也不太可能。说来残酷,最能压的还是CODING,编码阶段往往是压缩重点,总之大家埋头苦干就是了,大项目压缩的时候程序员吃喝拉撒都在公司是很正常的事情,相信不少人都有很深的体会,这里伤心事情也就不提了。只是我总结一下,让未来的PM们有压榨后来人的依据,呵呵。测试前期也可以适当的压一压,那时候人刚完工,都比较懒散。国内一般企业规模都不大,没有专门的质量控制部门,所以质量保证和测试往往就是程序员或PM本身。其实质量保证和测试人员的人数和素质都应该要高于程序员。在日本和CMM实施的公司里,编码压缩是很容易实现的事情,因为那些程序员真的是技能熟练的装配工人,压起来方便的很。他们这样培养人的目的或许就是为了压缩吧?!

    四.控制和执行阶段

    1.软件开发
    实在没什么好说的,也是大家最不愿意谈的,平时在公司里谈的已经够多的了,还要在这里受我唠叨。需要提醒的依然是团队合作精神和完善的文档管理制度。SOURCESAFE这些工具有时候还是有必要使用的。经常看到有人说天才程序员不写注释什么的。我相信有这种天才程序员,因为我碰到过几个。我爱人公司里也有一个,他们的一套产品核心代码就是这个人写的,4年过去了,周边代码换了好几茬,核心算法始终没换过,可惜这小子跟了李洪痔,如今已经不知所踪了。但是他的代码似乎也要有点注释的,没有注释过段时间再天才的程序员也不能保证他是最有记忆力的。而且,对一个项目的编码来说,靠一两个人打天下如今是不可能了。别人的公司都是团队,两人智慧胜一人,这头还在靠一个天才支撑门面,实际上市场可就别人抢了去,那时候再天才也没用了。编码的时候讲究技术公开,程序员不要藏着掖着,对大家没好处,PM要想办法调动大家创新思维的积极性,营造良好的技术讨论氛围,碰到技术难关的时候就容易攻破了。

    有个问题需要单独对还没有PM觉悟的程序员说,其实是在调研的时候就定了的,就是使用什么样的开发工具。没有经验的程序员往往会拿着C++或者 JAVA的资格证书或者拥有一两个开发工具的一些经验而得意洋洋。其实老板和PM根本不看重这个,他们关心的是使用什么样的工具能尽快的达到目的。管你什么C++,DELPHI,PB还是JAVA,只要能做的出来,VFP都可以用。我举这个例子并非说不看中工具,而是提醒想转型为PM的程序员,第一要把工具当作工具,而不要被工具套进去,钻研一些一辈子都用不上的技术;第二要掌握的并非是单独的一个工具,而是流行的程序设计的思想,以及在最短时间内掌握一门陌生工具的能力。只有建立了这样的思维,才有可能转为PM,否则一辈子都是技术工人,最多就是个技术总监。

    2.变更
    对任何项目,变更无可避免,无从逃避,只能去积极应对,这个应对应该是从需求分析就开始了。对一个需求分析做的很好的项目来说,基准文件定义的范围越详细清晰,用户跟PM扯皮的幌子就越少。而需求没做好,基准文件里的范围含糊不清,被客户抓住空子搞你一下是非常头疼的事情,往往要付出无谓的牺牲,有时候甚至非常火大。

    需求做的好,文档清晰又有客户签字,那么后期客户提出的变更就超出了合同的范围,需要另外收费。这个时候千万不能手软,并非要刻意赚取客户的钱财,而是不能养成客户经常变更的习惯,否则后患无穷,维护的成本会让PM吃不消。在客户提出变更请求时,要建立变更申请登记表和变更申请表,并让客户签字。当然,有时候一些不是非常关键的模块PM也不至于一点不讲情面,该卖面子的时候还是要卖,尤其是当着对方领导的面,千万要卖面子,但是也别卖的太干脆,不要让他们得到的太容易。

    需求做的不好,客户抓住漏洞或者非常不讲道理,麻烦就大了。有时候争论会很厉害,到非常白热化的地步,PM与客户代表几乎沟通不了。PM在客户关系和短期利益两方面难以取舍,一般都是向客户妥协,最终形成恶性循环。这种情况非常难办。一般这种情况都是到了项目后期,做重大的更改几乎是不可能的事情,如果白做就要亏钱。而这个时候如果PM跟对方高层的人关系搞的定,可以透过对方高层把事情压住。然而由于已经到后期,客户代表不会轻易更换,对方这次没有改成,必然心怀不满,下回在别的模块依然会找麻烦或者在谈二期的时候动动手脚,都是很让PM伤脑筋的事情,这方面目前还没有什么好的解决方法,所以尽可能的做好需求比什么都重要。相对需求来说,什么WBS,风险管理,计划进度都是扯淡,需求做好了,一帆风顺。还有一种办法就是装可怜,要装的非常的象,在对方的领导面前装,而且不能让人看出是装的样子,要让你自己都觉得你自己是真的可怜,那么就算这次客户硬是要求改了,下回他也必然不好意思再叫你改。其实人心都是肉长的,如果可能的话,我还是不赞同使用一些手段的,但是有时候客户非常难以在短时间打动而工期又将接近,这种情况下就要靠PM耍一些手段了。各人有各人的方式,八仙过海,各显神通吧。

    PM在变更管理中需要做的是分析变更请求,评估变更可能带来的风险和修改基准文件。

    3.质量控制
    大公司有质量管理部门(QA),QA的成员基本上都是由非常有经验的PM转型过来的老狐狸,是老总接班人的有力争夺者。一个QA会管理多个项目,有时候甚至会亲身参与。PM和QA有些象猫和老鼠,不停的通过报表传递一些心照不宣的假数字。QA对PM的工作最终是有评定的:A级表示总体在控制下;B级表示当前在控制下;C级表示有显著问题;D级表示有重大问题。如果PM得了个D,那可不太妙,不但世界级的QA会每个月要收报告,地区QA会一个星期找来面谈一次,训一顿。得到A的PM是很逍遥的,基本上不会有人来过问。在没有QA的公司,质量控制只能由经过授权的团队成员进行,效果就要差的多了。
    质量管理贯穿整个项目周期,详细的可以参见CMM。

    4.成本管理
    PM经常通过控制进度和预估来控制成本。PM必须经常问自己,项目已经到了什么阶段?完成了多少?花费了多少?完成时成本是多少?挣值法的术语不少,象BCWS,BCWP,ACWP,但是关系比较简单,大家参阅一下相关资料,这里不再羸述。总之,PM要管理好成本,注意节约,但并非是拼命剥削程序员,该花的还是要花。

    五.结束阶段

    1.项目结束
    项目结束时,PM要将最终系统方案提交给用户,完成项目所有的提交件,收集项目全部信息并结束项目,完成或终止合约,签署项目结束的相关文件。

    项目结束意味着可以收钱了。PM辛苦了那么多,终于可以高兴一下了,收到最后一笔款项,意味着递交件的移交和团队的解散,项目也转入维护阶段。不过收钱未必代表着赚钱,要看项目是否按时完工。一般来说,提前完工的项目很少,但是能赚大钱;按时完工的赚小钱;延期的要赔钱。一个人首次承担PM,如果没有人带,多半会失败。失败没什么,所有的PM(注意是所有,不是几乎所有)都失败过,然而失败会成为教训和经验,推动你继续前行。在美国,每年至少有40%的项目无法实施被搁浅。只有在项目中和生活中不断磨练,培养自身素质和作人的基本准则,才能成为赚大钱的 PM。

    2.项目完工会议
    项目结束时,依然要开会,不过少多了。一般跟客户要开一个,主要是确定所有的提交件都已经被接收,对突出的个体进行表扬,对外宣传成功案例,标志并记录项目的正式结束。这时候开会很轻松,目的也很明确,做完了大家好聚好散,或者以后有机会再合作。
    团队要解散,内部会议肯定是要开的。也没什么好废话的,该表扬就表扬,该发多少奖金就发多少奖金,毕竟大家都累死累活的干了那么长时间。项目结束请客户出去泡温泉时PM们千万别忘记了辛苦为你工作的程序员和工程师们,当然,如果他们不愿意看到你的脸那么你就折现发到他们的存折上去,正好让他们回家好好休息休息。这样下一个项目需要他们的时候他们才会为你卖命。说出来奖金发出去似乎你损失了,其实你赚大了。

    3.客户满意度
    形势也好,历史记录也好,尽管项目结束的时候客户满意度PM心中已经有底了,但是还是有必要向客户各个层次的项目代表发一张信息反馈表,收回的信息将反应客户的满意度。其实真正体现客户满意度的地方有很多。第一就是付钱付的快,如果客户不满意,一分钱藏在他牙缝里你也很难抠出来;第二就是二期,二期非常非常重要,因为这里已经是属于一种无销售成本的项目,又有一期的经验,可以说二期的钱是最好赚的。这中间的感觉,只有经历过的人才明白。

    六.团队管理

    1.建立团队
    挑选人材依然是PM头疼的一个大问题,有时候一个在别的项目里很优秀的人材,挖过来未必能适应。所以,PM还是要拓展知识面,培养自己的敏锐度,因人置宜,才能挑选对自己项目有帮助的人材,才能真正对项目起作用。

    2.核心程序员
    任何项目都有核心程序员。核心程序员背负着很重的责任,平时要和普通程序员一样没日没夜的加班,碰到重大的技术难关更是整个人扑在电脑上,熬上几个通宵是家常便饭。常有人抱怨程序员工资高,真想请这些人来尝试一下程序员的工作,看看他们付出的精力是否配那份工资。前面说过的,中国的程序员不同于日本和欧美,他们很多人参与了系统分析和建模,对脚踏实地工作的程序员来说,这份工资实在是委屈了。看看行业里努力工作的程序员们,有几个不是头发花白,高度近视,未老先衰的?上星期五晚上我加班到10点,隔壁公司的一个技术总监特意留下来跟我说:“我们这种人,前半生拿命去换钱,后半生拿钱来买命!所以,工作的时候一定要注意劳逸结合!”道理我并非不懂,我也不想透支自己的身体,但是我有选择么?

    PM要特别注意爱护核心程序员,尤其是他们的生活困难和精神状况,有时候,他们耍性子或者不合作PM要妥协,要从自己身上找原因。其实在国内,我还没碰到过敢这么做的程序员。相对PM来说,程序员是绝对的弱势群体,没有任何发言权,几乎可以说PM想怎么做,想怎么改,程序员就要付出一切代价去达到目标。

    3.奖励与惩罚
    奖励是不用说的了,相信所有阅读我这篇文章的PM,未来的PM,程序员和未来的程序员们都知道如何去做,这里只说惩罚。惩罚似乎很不好办,其实对PM来说再简单不过。一个程序员把模块做砸了,骂,扣工资,开除都不顶用,在项目没完成之前不是追究责任的时候。一个优秀的PM应该给他一个机会,当作没事一样让他去做别的事情,把他做砸的事情交给别人去做,就是对他最大的惩罚。这样既能激励他上进又不会让他尴尬,他会感激你一辈子,因为你给了他一次机会。而PM挑选这个人进团队并给予他责任,他没有完成,PM本身就有责任,应该自我检讨。

    4.管理冲突
    无论团队里的成员相互之间很熟悉还是不熟悉,冲突再所难免。在发生冲突的时候PM要牢记以公开,公正的方式处理冲突,不能因为其中之一是自己的小姨子就干掉另一方;处理事情的时候必须对事不对人。有时候,成员与PM之间也会有冲突,一般情况下都可以几乎肯定是PM的责任,因为很少有成员敢吃豹子胆来反抗自己的顶头上司。这时候PM除了要及时的做自我检讨之外,要有宽广的心胸。绝对不可以利用职权打击与自己有矛盾的成员,否则团队里所有成员都会心寒,项目的质量将会大打折扣。如果他确实不对,也要忍住,等项目完了慢慢收拾他不迟。PM的心胸还表现在不能嫉贤妒能上。当公司高层越级表扬团队某成员时,你应该高兴和光荣,而不是阴险的想着下次如何把这份光环戴到自己的头上。实际上在国内的很多PM都是这么做的,邀功的时候全是他的,有了责任都在下面。这种PM永远做不大,迟早会被淘汰。

    5.承担责任
    项目是有风险的,肯定会有失败的部分甚至整个项目失败。虽然说每个人都在WBS里定下了责任,在项目里程碑里都有任务。但是当整个项目危机来临的时候,PM要勇于站出来,承担起全部的责任。这是做人的方式,也能让你赢得团队所有成员的尊敬和爱戴。往往在这个时候我们才能体会到什么叫团队合作精神,就是大家齐心合力,共渡难关。

    6.资源争夺
    前面提到过,资源有限,如何争夺而不伤和气是对PM的另一个挑战。因为整个公司是一个大团队,内耗的厉害对PM没有好处。当然,摆平各路神仙是不可能的。但是一个健康的公司必然有健康的管理制度和优秀的成员。物以类聚,人以群分,PM应该在公司里主动结交志气相投的朋友,在拿到项目时这些朋友会给你很大的帮助,当然,在这些朋友需要你帮助的时候你也应该懂得怎么做。如果你性子很怪,很难找到脾气相近的朋友,没关系,交几个酒肉朋友也不错。我们公司数据统计,一个人在公司的人缘和他在公司请客吃饭的次数成正比。PM一定要尽心尽力的为公司打算,这样在需要高层支持的时候才会获得鼎立相助,而总是为自己打小算盘的PM是不长久的,总会被别人看穿的。

     

    后记:写到这里实在写不动了,控制阶段的合约管理和项目跟踪没有写进去,一方面我不熟悉,另一方面让大家自己去做一些思索。其实前天我就在构思这篇文章了,本来还想把CMM也写一篇的,如今看来太高估自己的能力了,时间实在是不允许。抬头一看,东方已露鱼肚白,外面隐约传来麻雀的嬉叫声。今天我还要去跟人谈祖房子的事情,明天还要上课,星期一开始又要没日没夜的加班,多想睡个懒觉呀!

    0

    阅读 (110) 评论 (1) 收藏 (0) 转载 (0) 喜欢 打印 举报
    已投稿到:

    转载列表:

      转载

      转载是分享博文的一种常用方式...

      展开全文
    • 数据说明 kaggle要求 预测思路 相關 reference 可以參考: 报告题 1. 不同学习率收敛情况 2. 减少feature (只取后5h) 3. 减少feature (只取PM2.5) 4. 调整改进

      作业笔记被我手贱删了, 只能凭回忆重新总结个简洁版本的

      我用的是kaggle提供的在线notebook, 代码与部分思路公开在:

      https://www.kaggle.com/laugoon/homework1( 第一行注释中注明报告题目的cell, 在预测时无需运行 )

      不方便用kaggle也可以在CSDN下载源码:

      https://download.csdn.net/download/lagoon_lala/16721800

      其他好用的在线notebook还有:

      deepnote( 比colab多一些协作编程等功能 ):

      http://deepnote.com

      colab(需要能上谷歌), 这是台大给出的作业范例:

      https://colab.research.google.com/drive/131sSqmrmWXfjFZ3jWSELl8cm0Ox5ah3C

       

      目录

      数据说明

      kaggle要求

      预测思路

      相關 reference 可以參考:

      报告题

      1. 不同学习率收敛情况

      2. 减少feature (只取后5h)

      3. 减少feature (只取PM2.5)

      4. 调整改进


      数据说明

      PM2.5预测

      本次作業使用豐原站的觀測記錄

      train.csv: 每個月前 20 天的完整資料。

      test.csv : 從剩下的資料當中取樣出連續的 10 小時為一筆,前九小時的所有觀測數據當作 feature,第十小時的 PM2.5 當作 answer。一共取出 240 筆不重複的 test data,請根據 feature 預測這 240 筆的 PM2.5。

      Data 含有 18 項觀測數據 AMB_TEMP, CH4, CO, NHMC, NO, NO2, NOx, O3, PM10, PM2.5, RAINFALL, RH, SO2, THC, WD_HR, WIND_DIREC, WIND_SPEED, WS_HR。 

      kaggle要求

      Link: https://www.kaggle.com/c/ml2020spring-hw1

      預測 240 筆 testing data 中的 PM2.5 值,並將預測結果上傳至 Kaggle

      Upload format : csv file( kaggle上会有提交样例 )

      第一行必須是 id,value

      第二行開始,每行分別為 id 值及預測 PM2.5 數值,以逗號隔開。

      作 linear regression,方法限使用 gradient descent。

      禁止使用 numpy.linalg.lstsq

      预测思路

      我的代码https://www.kaggle.com/laugoon/homework1

      其中初次预测部分主要参考作业范例:

      https://colab.research.google.com/drive/131sSqmrmWXfjFZ3jWSELl8cm0Ox5ah3C

      补充一些作业范例中的思路图片:

      特征提取:

      原数据每18行为1个月, 放到横向

       

      每10h为一笔资料( 其中前9h为输入, 第10h为输出 ), 把输入输出分别保存

      线性回归实现, 梯度下降算法

       

       

      对测试集的输入预处理

      相關 reference 可以參考:

      Adagrad:

      https://youtu.be/yKKNr-QKz2Q?list=PLJV_el3uVTsPy9oCRY30oBPNLCo89yu49&t=705

      对应李宏毅该系列视频的梯度下降

      RMSprop :

      https://www.youtube.com/watch?v=5Yt-obwvMHI

      对应B站吴恩达:

      https://www.bilibili.com/video/BV1V441127zE?p=21&t=1

      Adam:

      https://www.youtube.com/watch?v=JXQT_vxqwIs

      对应B站吴恩达:

      https://www.bilibili.com/video/BV1V441127zE?p=22

      可以藉由調整 learning rate、iter_time (iteration 次數)、取用 features 的多寡(取幾個小時,取哪些特徵欄位),甚至是不同的 model 來超越 baseline。

      Report 的問題模板請參照 :

      https://docs.google.com/document/d/1s84RXs2AEgZr54WCK9IgZrfTF-6B1td-AlKR9oqYa4g/edit

      报告题

      備註 :

            a. 1~3題的回答中,NR 請皆設為 0,其他的數值不要做任何更動。

            b. 可以使用所有 advanced 的 gradient descent 技術(如 Adam、Adagrad)。

            c. 1~3題請用linear regression的方法進行討論作答。

      1. 不同学习率收敛情况

      1. (2%) 使用四種不同的 learning rate 進行 training (其他參數需一致),作圖並討論其收斂過程(橫軸為 iteration 次數,縱軸為 loss 的大小,四種 learning rate 的收斂線請以不同顏色呈現在一張圖裡做比較)。

      关于matplotlib, 太久没用, 重点补了一下这次用到的, 可以看博客旁边一篇"作图笔记"

      全部数据直接生成出来, 第一次长这样

      观察数据之后, 发现是前几个点太大了, 导致后面看起来像长尾, 考虑缩小y轴显示范围. 最终显示结果:

      在其他参数不变的情况下, 学习率为2左右收敛情况最好, 学习率小于1后 收敛速度反而显著变慢

      2. 减少feature (只取后5h)

      2. (1%) 比較取前 5 hrs 和前 9 hrs 的資料(5*18 + 1 v.s 9*18 + 1)在 validation set 上預測的結果,並說明造成的可能原因(1. 因為 testing set 預測結果要上傳 Kaggle 後才能得知,所以在報告中並不要求同學們呈現 testing set 的結果,至於什麼是 validation set 請參考:https://youtu.be/D_S6y0Jm6dQ?t=1949 2. 9hr:取前9小時預測第10小時的PM2.5;5hr:在前面的那些features中,以5~9hr預測第10小時的PM2.5。這樣兩者在相同的validation set比例下,會有一樣筆數的資料)。

      预测时原本用的是全部训练集, 本题要求使用划分训练/验证集后的数据.

      划分后训练时, 拼接常数项参数的矩阵形状, 标准差计算时的总个数都要改变.

      此外, 还要提取后5小时的属性作为训练, 测试集的输入. 要进行提取, 首先要明白处理后的x形状.

      x [12 * 471, 18 * 9], y [12 * 471, 1]

      行数的含义为一年12mon*每月471笔数据

      列数的含义为每笔数据含10h, 其中9h在x, 1h在y.

      np多维数组分片时不用加iloc, dataframe需要.

      在训练出验证集的y后需要考虑如何衡量预测结果, 看到老师在上课时用的是平均误差, 所以决定用这个. ( 也看过一些同学用loss )

      最后平均误差结果: 9h的3.5+ 5h的3.4+

      可能的原因为. 前4h对第10h的PM2.5影响不大,甚至有点过拟合.

      3. 减少feature (只取PM2.5)

      3. (1%) 比較只取前 9 hrs 的 PM2.5 和取所有前 9 hrs 的 features(9*1 + 1 vs. 9*18 + 1)在 validation set上預測的結果,並說明造成的可能原因。

      9*18 + 1的部分仍可用上题预测出的结果

      9*1 + 1

      需要找到PM2.5的那部分

      开始看原始数据读入时每把表头算入, 而且从0开始计, 所以是第9行.

      只取第9行会报错

      all the input arrays must have same number of dimensions, but the array at index 0 has 2 dimension(s) and the array at index 1 has 1 dimension(s)

      单独一行, 外面没套那一层, 所以退化成一维数组了

      然后想起来训练数据集是处理过的, 已经不是这个形状了

      x [12 * 471, 18 * 9], y [12 * 471, 1]

      每笔数据的PM2.5应该在第9列, 18+9列…以此类推

      循环提取, 整列赋值参考:

      https://blog.csdn.net/PJCKR/article/details/95453642

      赋值是没问题的, 最后找到问题在于定义数组形状的时候没*0.8(这是划分训练集, 验证集后的大小)

      碰到这样的报错:

      shapes (4521,11) and (10,1) not aligned: 11 (dim 1) != 10 (dim 0)

      那一般是加常数参数项的单元格被多次执行了, 9*1+1变成了9*1+2

      最后得到平均误差结果:

      所有属性: 4.63735404055456

      只看PM2.5: 12.194386766277699

      可能原因: 其他属性中有些对PM2.5的起关键作用.

      4. 调整改进

      4. (2%) 請說明你超越 baseline 的 model(最後選擇在Kaggle上提交的) 是如何實作的(例如:怎麼進行 feature selection, 有沒有做 pre-processing、learning rate 的調整、advanced gradient descent 技術、不同的 model 等等)。

      根据验证集预测的结果, learning rate=2, 取后5h的效果比较好, 其他属性中有重要的, 但是要去除不重要属性还是需要分析. 属性太多画图是不方便了, 一会看看哪个w比较大.

      w依次对应x的一行(一笔数据), x[12 * 471, 18 * 5]

      x的每一行是h5的18个属性, … h9的18个属性

      5h训练得到的w:

      AMB_TEMP

      -1.61E-01

      2.81E-02

      -5.09E-01

      -3.30E-02

      -2.09E-01

      CH4

      2.09E-01

      -8.12E-03

      4.11E-01

      3.04E-01

      -1.52E-01

      CO

      9.15E-02

      -1.23E-01

      -5.95E-02

      -4.90E-02

      2.51E-01

      NMHC

      1.07E-01

      1.56E-03

      -1.74E-01

      2.48E-01

      9.93E-02

      NO

      -4.19E-01

      -8.53E-02

      3.30E-02

      7.38E-02

      -1.68E-01

      NO2

      8.84E-02

      1.16E-01

      1.31E-01

      1.48E-01

      -1.62E-01

      NOx

      1.32E-01

      7.35E-02

      -3.92E-01

      -2.42E-01

      -5.54E-02

      O3

      -4.32E-01

      -1.05E-02

      1.53E-01

      1.33E-01

      -1.02E-01

      PM10

      1.82E+00

      -1.27E-01

      7.70E-01

      4.35E-02

      -1.21E-02

      PM2.5

      -2.68E-01

      1.73E-02

      -2.25E-04

      -1.95E-01

      -6.87E-02

      RAINFALL

      4.22E-01

      3.12E-01

      -1.59E-01

      -1.16E-01

      2.97E-01

      RH

      1.41E+00

      1.29E-01

      2.94E-02

      2.69E-02

      -1.51E-01

      SO2

      -2.19E+00

      -9.66E-02

      -2.72E-01

      -2.54E-01

      -3.07E-01

      THC

      4.15E-01

      -1.69E-01

      1.62E-01

      4.98E-02

      -5.67E-02

      WD_HR

      5.29E+00

      6.34E-01

      6.48E-02

      2.88E-02

      3.79E-01

      WIND_DIREC

      -7.38E+00

      -8.56E-01

      -3.10E-02

      -2.59E-03

      -1.94E-02

      WIND_SPEED

      7.51E-01

      4.28E-02

      -6.34E-02

      -1.90E-01

      -2.53E-01

      WS_HR

      1.52E+01

      -5.54E-01

      7.75E-01

      1.03E-01

      9.33E-02

      常数

      2.14E+01

          

      绝对值, 每h分别排序, w最小的feature分别为

      第一次

      第二次

      第三次

      第四次

      第五次

      NMHC(2)

      O3

      WIND_DIREC(3)

      WD_HR

      NOx

      CO

      CH4

      RH(2)

      RH

      WIND_DIREC

      NO2

      NMHC

      PM2.5

      WIND_DIREC

      PM10

      有点奇怪. w由时间前到后越来越小, 但最后一笔数据最靠近预测日期, 应该影响更大啊.

      而且没有固定的某个属性对PM2.5影响很小, 决定不对属性动手了

      用后5h的数据训练, 虽然验证集误差稍小, 但测试集得分很低

      比较下loss, 是5.861416265758481, 相差不大, 比原来好些, 原来loss收敛到貌似7+

      loss没有问题, 但输出就是很离谱, 可能测试集的输入处理有问题

      #测试集输入数据标准化结果有问题

      for i in range(len(test_x_5h)):

          for j in range(len(test_x_5h[0])):

              if std_x[j] != 0:

                  test_x_5h[i][j] = (test_x_5h[i][j] - mean_x[j]) / std_x[j]

      test_x_5h = np.concatenate((np.ones([240, 1]), test_x_5h), axis = 1).astype(float)

      此处输出不太对, 考虑是std, mean不合适. 训练集是先标准化再取后5h

      训练集标准化时用的是:

      mean_x = np.mean(x, axis = 0) #18 * 9

      std_x = np.std(x, axis = 0) #18 * 9 标准差

      重新标准化后得分好很多, 没那么离谱了: 9.24833

      说明重新标准化是有必要的, 但很奇怪之前作业范例中, 测试集的标准差和均值用的是训练集生成的.

      试了试完整数据集预测时重新标准化, 效果不如5h( 和5h相似, 9.5 ), 也不如第一次.

      担心是其他环节影响了数据, 控制变量, 只把std, mean换回来. 还真的没问题.

      说明使用完整训练集预测时, 在测试集中, 输入数据的标准化时, 使用训练集的期望标准差, 结果好很多. 使用9h而非5h的训练集结果好很多.

      就只剩下修改学习率了, 学习率根据第一问的最佳结果改成了1, 居然分数迅速变好, 5.57977

      真是哭笑不得, 太菜了用了那么多馊主意改模型, 最后还不如调参数.

      展开全文
    • PM什么意思

      千次阅读 2010-12-22 17:13:05
      请注意:本文章的 pm不涉及 论坛上private message (私下发信息)和 下午post meridiem 等意思。旨在探讨产品工程师这种职业的工作内容和职责,如有好的相关信息请联系觉得这个职业能锻炼你...
    • 很高兴宣布推出一本名《 人类可读杂志》的新编程杂志。 多年来,这一直是的梦想,而且,由于我们成功地发行了晨报的编码杯,现在它已成为现实。 该杂志秉承时事通讯的精神,汇集了素质的编程专家,深入...
    • 为什么产品经理总被吐槽是”水货

      千次阅读 2019-01-29 18:23:24
      最近年底了,总参加各种聚餐...空降的产品经理就是部门缺人,从外面社招的,校招就不提了,基本上校招来的大家也不会抱太期望。空降的产品基本上十个有八个会被吐槽水,如果是转行的那种,比如本来做BI产品转化做...
    • shim12 03:41:56 PM 0 10804 0.00 0.98 0.00 4.90 0.98 1 kworker/1:013 03:41:56 PM 0 10835 0.98 3.92 0.00 0.00 4.90 1 containerd-shim14 03:41:56 PM 101 10891 0.00 5.88 0.00 15.69 5.880 nginx15 03:41:56 ...
    • 今天期末考试过后突然闲下来,翻书翻着翻着突然想起了一个问题:为什么,Why we need the imaginary number? ,为什么我们需要用到虚数iii? 然后的数学物理大厦又双叒叕(yòu shuāng ruò zhuó)崩塌了 ...
    • React服务端渲染+pm2自动化部署

      千次阅读 2018-07-30 18:02:56
      本文是直接着手SSR部分的并通过实战讲述自己遇到的一些问题和方案,需要大家有一定的React,node和webpack基础能力。skr,skr。 服务端渲染 Server Slide ...为什么要用SSR? 首先我们需要知道SSR对于SPA...
    • 蓝色关注,回复“1”获取知名公司程序员和产品经理职级第「135」篇原创。产品经理程序员,职场问题找军哥。见字如面,是军哥。前几天读者群里有一位伙伴说,部门有几位同事技术不怎么样,但...
    • 想多数同学的心理预期就是你可以学到一个很潮的人工智慧。我们知道,从今年开始,人工智慧这个词突然变得非常非常非常的热门,讲大家、政府通都在讲人工智慧这个词。 但人工智慧是什么呢?人工智慧其实一点都不是...
    • (小程序内容获取的时候是不能知道当前内容有几行的,可能有人会说,知道字体大小一行内放几个字,几行就再乘以几,让后台算好,传两个字段,展开收起,分别用两个字段即可,理论上是可行的(...
    • 主要介绍了其近几年在阿里电商平台及阿里云上的可用设计的经验,分为两个部分:第一部分主要包括传统的淘宝店铺稳定性体系的建设及相关的基础链路设计、缓存和容灾方案的设计及部署;第二部分主要包括...
    • Linux电源管理(2)_Generic PM之基本概念和软件架构作者:wowo 发布于:2014-5-13 19:24分类:电源管理子系统1. 前言这里的Generic PM,是蜗蜗自己起的名字,指Linux系统中那些常规的电源管理手段,包括关机(Power ...
    • 什么是静态化API?静态化API可以理解成把一些接口的数据存储在服务器本地。常用的是存成json文件,也可以是放在swoole的table中,总之是用户不从数据库直接读取数据,而是从本地加载的方式来大幅提高性能,因为很多...
    • PM Related Topic 2

      2013-10-25 13:26:43
      的选择是VSS。 2. 你们的项目组使用缺陷管理系统了么? 应该用。ClearQuest太复杂,的推荐是BugZilla。 3. 你们的测试组还在用Word写测试用例么? 不要用Word写测试用例(Test Case)。应该用一个专门的系
    • SM4 并发代码 压测 日志 报告 百万并发 4秒
    • 但是,为什么有些BUG是不能修改的呢?当一个特性以代码的形式进入产品的时候,就伴随着各种各样的BUG,直到发布之前,都会一直处于发现BUG,修复BUG的循环中。出现了BUG就要修复,这似乎是再自然不过的事情了。但是...
    • 宋志平会长分享的时候讲到现在什么资源都过剩,但有一个资源在企业里反而是稀缺的,就是人才。小企业缺人才,大企业也缺人才,领先的企业仍然缺人才,到底人才去哪儿了呢? 我们发现,现在的人才稀缺,主要有两个...
    • 为什么使用Linux

      千次阅读 2016-12-29 22:45:16
      已经半年没有使用 Windows 的方式工作了。Linux 高效的完成了所有的工作。 GNU/Linux 不是每个人都想用的。如果你只需要处理一般的事务,打游戏,那么你;)%0 不需要了解下面这些了。7rm?zA ©达内科技论坛 – ...
    • 前段时间,在修订《淘宝十年产品事》一书,翻到当时收集的一些前辈的观点,发现依然很有启发 ,分享一下。言论的时间是2011~2012年间,当时,和几位同事在负责阿里产品经理的培养事宜,所...
    • 为什么软件开发的实际工作量通常估计的几倍? 我们来看一个故事就明白了:作者:Michael Wolfe翻译:童角大王我们决定沿着旧金山到洛杉矶的海岸线来一次远足旅行...
    • 现实中很多企业家都很强势,有些强势的领导带领企业走向了强大,而有些缺垮了,到底为什么呢? 作者:黄文锋,暨南大学管理学院教授 来源:华夏基石e洞察 企业家作为一个群体,有许多普遍的标签:偏执狂、神经...
    • 有的人因为喜欢代码的对话逻辑,有的人因为看中程序员的较薪资。有人追名,有人逐利,有人为了梦想,还有人仅仅只是想做些实际的小事。你的答案,又是什么?写在前面前几天和两位发小聚餐,我们三个人都选择了...
    • 本文产品猎人“Hunter”计划投稿作品不少PM都对同行人士“装逼”深有同感:他们动不动就搬上方法论,逻辑,同理心……更让人吐槽的是,一个二个没生过孩子的说产品就是自己孩子……把简单道...

    空空如也

    空空如也

    1 2 3 4 5 ... 20
    收藏数 3,776
    精华内容 1,510
    关键字:

    为什么家里pm25比外面高